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Greater  Combat  Effectiveness 


I  recently  attended  a  briefing  given  by  an  F-16  pilot  who  had  flown  many  missions 
in  Operation  Iraqi  Freedom.  He  could  not  have  been  more  complimentary  of  the 
group  of  software  managers  and  engineers  that  he  was  addressing.  As  he  mentioned 
numerous  times,  he  flies  the  planes  but  it  is  the  engineers  who  are  designing  and 
coding  the  software  that  in  turn  enables  him  to  do  his  job  better  and  put  “bombs 
on  target.” 

As  a  software  engineer,  it  is  easy  to  get  immersed  in  the  nitty-gritty  programming 
aspects  of  your  job  and  lose  sight  of  the  bigger  picture.  In  this  month’s  issue,  we  highlight  the 
bigger  picture  of  how  software  plays  an  ever-increasing  role  in  the  U.S.  military’s  combat 
effectiveness. 

In  Software  Wars  by  Susan  Weaver,  we  begin  with  a  look  at  how  software  has  evolved  to 
become  a  key  enabler  for  the  Navy’s  dual-role  F/A-18  Hornet  aircraft.  This  article  describes  the 
increased  capability  made  possible  through  the  software  of  onboard  systems  such  as  the  dual¬ 
role  radar,  heads-up  and  heads-down  displays,  weapon  delivery  systems,  and  the  avionic’s  digital 
multiplex  bus  architecture. 

Next,  in  Tomahawk  Cruise  Missile  Control:  Providing  the  Right  Tools  to  the  Wa  fighter  by  Marcus 
Urioste,  the  Tactical  Tomahawk  Weapon  Control  System  (TTWCS)  is  described.  The  TTWCS 
program  enables  a  reduction  in  the  Tomahawk  timeline  by  placing  the  missile’s  mission  planning 
function  aboard  the  firing  unit.  This  article  discusses  this  major  software-based  reengineering 
upgrade  program  aimed  at  bringing  more  capability  to  officers  and  sailors  onboard  U.S.  surface 
ships  and  fast  attack  submarines. 

Software  also  plays  a  key  role  in  the  move  toward  a  joint  net-centric  warfare  capability.  As  an 
information  infrastructure,  the  Global  Information  Grid  (GIG)  will  improve  data  routing  and 
shared  situational  awareness.  In  Service-Oriented  Architecture  and  the  C4ISR  Framework,  Dr.  Yun- 
Tung  Lau  presents  a  modeling  approach  that  has  been  applied  to  the  architecture  development 
of  Net-Centric  Enterprise  Services  (NCES).  The  NCES  provides  the  core  enterprise  services 
supporting  various  communities  of  interest  to  the  GIG. 

In  our  Software  Engineering  Technology  section,  we  bring  you  three  articles  that  describe 
technology  advancements  to  further  sharpen  the  software  edge.  First,  in  Executable  Specifications : 
Tanguage  and  Applications  by  Dr.  Doron  Drusinsky  and  Dr.  J.L.  Fobes,  a  formal  method  of  ver¬ 
ification  is  described  that  can  be  applied  to  requirements  simulation  before  software  imple¬ 
mentation,  as  well  as  to  a  variety  of  other  defense  applications  to  ensure  safety  and  security. 
Second,  in  Executable  and  Translatable  UME  by  Stephen  J.  Mellor,  learn  the  fundamental  ideas 
behind  Executable  and  Translatable  UML  and  how  it  works  in  practice  to  accelerate  develop¬ 
ment  and  improve  the  quality  of  systems.  Many  senior  level  managers  rely  on  project  managers 
to  present  pertinent  measurement  data  that  enables  the  decisions  they  make.  In  What  You  Don’t 
Know  Can  Hurt  You ,  the  third  article  in  this  section,  author  Douglas  A.  Ebert  provides  helpful 
questions  for  senior  managers  to  ask  their  project  managers  to  ensure  the  proper  set  of  met¬ 
rics  is  being  collected  for  them  to  act  upon. 

Finally,  Identifying  Essential  Technologies  for  Network-Centric  Warfare  by  David  Schaar  is  our 
Open  Forum  article  that  shares  this  author’s  opinion  and  research  on  network-centric  war¬ 
fare  (NCW).  Schaar  discusses  NCW  from  its  concept  definition  to  its  role  in  the  battlespace 
to  the  technologies  needed  to  enable  concepts,  including  better  awareness  of  the  enemy  and 
friendly  forces. 

As  shown  in  this  set  of  articles,  it  is  clear  that  software  plays  a  big  role  in  increasing  the 
warfighter’s  combat  effectiveness.  The  F-16  pilot  I  listened  to  showed  obvious  joy  in  describing 
what  software  brings  to  his  job  today.  I  can  only  imagine  what  he  might  be  saying  about  its 
impact  10  years  from  now. 
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Susan  Weaver 

F-3  Communications  Government  Services,  Inc. 

The  basic  premise  behind  the  F/A-1 8  aircraft  design  was  that  capability  growth  could  be  achieved  through  software  upgrades 
rather  than  requiringfrequent  hardware  changes  to  increase  functionality.  At  least  that  was  the  vision  back  in  the  late  1970s 
when  the  concept  for  the  F/A-1 8  aircraft  was  first  developed.  The  F/A-1 8  platform’s  recent  return  to  the  Persian  Gulf 
region  has  provided  us  with  a  rare  opportunity  to  examine  the  extent  to  which  we  have  been  able  to  achieve  capability  growth 
through  software  upgrades,  and  to  consider  the  lessons  we  have  learned  as  a  major  military  system. 


The  U.S.  Navy’s  F/A-1 8  Hornet  is  a  sin¬ 
gle-  and  two- seat,  twin  engine,  multi¬ 
mission  fighter/ attack  aircraft  that  can 
operate  from  either  aircraft  carriers  or  land 
bases  [1].  The  F/A-1 8  relies  on  two  prima¬ 
ry  mission  computers  for  navigational  con¬ 
trol  and  weapons  employment.  The  origi¬ 
nal  F/A-1 8  A/B  model  aircraft  mission 
computers  use  1970s  software  technology 
with  32  thousand  (K)  of  memory  in  each 
computer.  From  the  start,  the  F/A-1 8 
Hornet  was  designed  to  perform  both  the 
fighter  and  attacker  roles.  To  support  these 
dual  roles,  multi-function  programmable 
radar  was  created.  Instead  of  being  wired 
to  do  just  one  job,  the  radar  would  be  soft¬ 
ware  reprogrammable. 

A  programmable  radar  signal  processor 
and  data  processor  provide  the  flexibility  to 
change  missions  and  select  radar  mode 
based  on  pilot  inputs.  For  example,  the 
F/A-1 8  uses  the  same  radar  for  air-to-air 
target  acquisition  and  tracking,  as  well  as 
air-to-ground  Doppler  beam  sharpened 
target  mapping.  Another  key  element  was 
breakthrough  technology  in  human  factors 
and  the  pilot-to-vehicle  interface  allowing 
an  effective  one-man  operation. 

A  concern  in  designing  a  dual  role  air¬ 
craft  was  how  to  provide  all  the  informa¬ 
tion  the  pilot  needed  to  effectively  perform 
the  mission  without  overwhelming  the 
pilot  with  information.  An  innovation 
incorporated  into  the  Hornet  for  one-man 
operation  is  the  combination  of  the  heads- 
up  display  (HUD)  and  three  heads-down  dis¬ 
plays.  As  the  pilot  looks  through  the  HUD 
toward  the  sky,  the  land,  or  the  sea,  dynam¬ 
ic  symbols  are  presented  displaying  every¬ 
thing  the  pilot  needs  to  safely  fly  the  plane 
and  deliver  weapons.  The  HUD  displays 
symbols  that  are  projected  at  infinity,  elim¬ 
inating  the  need  for  the  pilot’s  eyes  to  refo¬ 
cus  from  long  distance,  or  infinity,  to  the 
instrument  panel,  which  reduces  incidences 
of  vertigo. 

Twenty  buttons  used  to  manipulate 
information  presented  on  the  screen  sur¬ 
round  each  heads-down  display.  By  push¬ 


ing  one  button,  the  pilot  can  see  a  menu  of 
available  choices.  Then,  by  pushing  addi¬ 
tional  buttons,  a  diagram  of  the  weapons 
being  carried  is  displayed.  The  pilot  selects 
a  weapon  for  use  and  enters  a  delivery  pro¬ 
gram  (e.g.,  number  of  weapons  to  be 
released,  release  interval,  fusing  options). 

Two  of  the  three  heads-down  displays 
are  identical,  allowing  one  display  to  back 
up  the  others  in  a  malfunction.  The  third 

“The  efficiency  and 
effectiveness  of  the 
weapons  were  increased 
through  minor  upgrades 
to  software.  Our  ability 
expanded  from  delivering 
multiple  weapons  on  a 
single  target  to  delivering 
multiple  weapons  on 
multiple  targets.” 


display  can  project  a  moving  groundmap 
combined  with  additional  situational 
awareness  or  navigational  data.  This  map  is 
programmed  to  follow  aircraft  movement 
showing  aircraft  position  relative  to  specif¬ 
ic  ground  features  (e.g.,  roads,  railroad 
tracks,  cities). 

The  HUD  and  three  heads-down  dis¬ 
plays  work  in  concert  via  their  software 
programming.  For  example,  air-to-air  tar¬ 
gets  may  be  displayed  from  a  bird’s  eye  view 
on  one  of  the  heads-down  displays,  while 
the  HUD  displays  a  line-of- sight  cue  (from 
the  pilot’s  viewpoint)  outlining  the  highest 
priority  target  and  current  weapon  selected. 
In  all  cases,  critical  information  on  the 
heads-down  display  screens  also  appears 


via  the  HUD,  usually  in  a  graphical  format 
designed  for  rapid  pilot  comprehension. 

The  center  instrument  panel  contains 
the  up-front-control  panel.  The  aircrew 
uses  the  10-digit  keypad  panel  to  change 
radio  frequencies  or  enter  data  such  as  tar¬ 
get  latitude /longitude.  A  pilot  sometimes 
changes  radio  frequencies  as  many  as  40 
times  an  hour.  After  a  little  practice,  this 
placement  allows  the  pilot  to  change  fre¬ 
quencies  without  looking. 

During  a  dogfight  maneuver,  push¬ 
button  selection  may  be  difficult  due  to 
the  number  of  G-forces  being  endured  by 
the  pilot.  Therefore,  all  controls  needed  to 
manipulate  the  Hornet  during  stressful 
maneuvers  are  located  on  the  engine 
throttles  and  the  flight  control  stick.  This 
convention  is  termed  hands-on  throttle  and 
stick.  This  enables  the  pilot  to  select  radar 
modes,  weapons,  and  targets  and  control 
engine  power,  all  with  the  touch  of  a  fin¬ 
ger.  Designers  of  the  F/A-1 8  knew  a 
pilot’s  survival  might  depend  on  a  swift 
response  in  dealing  with  attacks  from  a 
hostile  fighter. 

Deployment 

The  first  real  test  of  the  F/A-1 8  A/B  came 
in  1986  with  air  strikes  against  Libya.  An 
F/A-1 8  aircraft  attached  to  the  U.S.S.  Coral 
Sea  launched  high-speed  anti-radiation 
missiles  against  Libyan  air  defense  radars 
and  missile  sites,  effectively  silencing  them 
during  the  attacks  on  Benghazi  facilities  [1] . 
After  the  attack,  the  F/A-1 8  s  were  armed 
and  ready  to  counter  any  air-to-air  or  air-to- 
ground  threat  the  Libyans  may  have 
planned. 

During  this  timeframe,  the  entire  air¬ 
craft  contained  approximately  one  million 
lines  of  code.  Early  F/A-1 8s  contributed 
in  multiple  areas,  primarily  the  air  defense 
role  in  the  form  of  combat  air  patrol  and 
suppression  of  enemy  air  defense.  Like  all 
later  model  F/A-1 8s,  all  necessary  infor¬ 
mation  to  land  on  the  aircraft  carrier  is 
available  on  the  HUD.  This  eases  the  effort 
required  by  the  aircrew  to  get  aboard  and 


4  CROSSTALK  The  Journal  of  Defense  Software  Engineering 


September  2004 


Software  Wars 


land  safely  on  the  carrier. 

Operation  Desert  Storm 

In  1987,  the  next  major  variant  of  the 
Hornet  (F/A-18  C/D)  was  released  to  the 
fleet.  The  early  F/A-18  C/D  models  uti¬ 
lized  256K  processing  power  in  each  of  its 
primary  computers,  with  later  model  C/D 
aircraft  possessing  2,1 12K  memory  for 
each  primary  processor,  and  a  total  of  six 
million  lines  of  code  in  the  aircraft. 

To  understand  the  significance  of  the 
F/A-18  C/D’s  dual  role,  lone  operator,  and 
system  capabilities,  it  is  useful  to  imagine 
what  it  is  like  for  a  pilot  to  bomb  an  enemy 
target.  The  following  is  Navy  Lt.  Nick 
Mongillo  and  Lt.  Cmdr.  Mark  Fox’s  recol¬ 
lection  of  an  event  that  occurred  during 
Desert  Storm. 

Fox  and  Mongillo  had  launched 
their  first  combat  mission.  Carrying 
four  2,000-pound  bombs,  two 
AIM-9  heat-seeking  Sidewinder 
missiles,  two  AIM-7  Sparrow  radar- 
guided  missiles,  and  a  centerline  330 
gallon  external  fuel  tank,  the  F/A- 
18s  made  their  way  toward  the  des¬ 
ignated  target  approximately  550 
miles  from  the  carrier. 

As  they  approached  the  target  area, 
the  pilots  had  their  radar  in  air-to- 
ground  mode  when  they  suddenly 
received  word  of  approaching 
enemy  fighters.  “The  E-2  (early 
warning  aircraft)  gave  us  a  call  say¬ 
ing,  'Bandits  on  nose  at  15,’  which  is 
a  confirmed  bad  guy  at  15  miles,” 
recalled  Fox.  “We  quickly  went  back 
to  our  radar  search  mode,  got  locks 
on  them,  confirmed  they  were  bad 
and  shot  them  both  down.” 

Fox  fired  two  shots  to  down  the 
first  MiG:  a  Sidewinder  followed  by 
a  Sparrow.  Both  missiles  hit  the 
Iraqi  jet,  and  the  exploding  MiG 
was  clearly  visible  on  the  videotape 
that  recorded  the  action  through 
the  HUD.  “I  fired  a  Sidewinder  at 
what  seemed  to  be  a  relatively  long 
range,  but  it  wound  up  working.  I 
wasn’t  sure  it  was  going  to  do  that, 
so  I  fired  a  Sparrow  to  make  sure,” 
said  Fox. 

Mongillo’s  kill  came  only  a  few  sec¬ 
onds  after  Fox’s  and  was  made  at 
close  range  with  a  Sparrow.  It  was 
also  clearly  visible  on  the  HUD 
videotape.  Furthermore,  the  tapes 
show  two  retreating  MiGs  were 
within  missile  range  when  the 


Hornets  disengaged  to  complete 
their  bombing  run.  Both  Hornets 
then  dropped  their  bombs  on  target 
from  an  altitude  of  18,850  feet. 
“The  idea  of  a  strike  fighter  is  valid. 

Fm  not  going  to  make  any 
grandiose  claims,  but  I  do  believe 
we’re  the  first  guys  to  kill  anybody 
while  carrying  8,000  pounds  of 
bombs,”  said  Fox.  [2] 

Overall,  more  than  210  U.S.  Navy, 
Marine  Corps,  and  Canadian  F/A-18 
Hornets  were  engaged  in  Operation  Desert 
Storm.  More  than  6,000  targets  were  hit  by 
Hornet  aircraft  flying  a  variety  of  missions 
from  fleet  air  defense  to  reconnaissance  to 
suppression  of  enemy  air  defenses  to  neu¬ 
tralizing  ground  forces.  The  F/A-18  air¬ 
craft  delivered  18  million  pounds  of  ord¬ 
nance,  and  clocked  more  than  30,000  flight 
hours  while  flying  1 1 ,000  sorties  —  an  aver¬ 
age  of  1.2  sorties  per  day.  Throughout 
Desert  Storm,  the  aircraft  averaged  90  per¬ 
cent  readiness.  Hornets  completed  95  per¬ 
cent  of  scheduled  sorties  and  missed  none 
for  maintenance  reasons  [3]. 

Desert  Storm  was  the  first  major  con¬ 
flict  to  make  use  of  smart  software-enabled 
bombs  like  the  Joint  Standoff  Weapon 
(JSOW).  Smart  weapons  can  be  pro¬ 
grammed  before  aircraft  takeoff  to  execute 
a  series  of  software-controlled  navigational 
changes.  These  navigational  changes  mini¬ 
mize  the  risk  of  the  weapon  being  disabled 
by  enemy  fire  before  reaching  its  assigned 
target.  Maverick  anti-tank  missile  and  laser- 
guided  bombs  developed  during  the 
Vietnam  War  continue  to  be  very  effective 
against  high-value  targets. 

The  heart  of  the  F/A-18  is  the  integra¬ 
tion  of  software  and  hardware  into  a  single 
system.  During  Desert  Storm,  F/A-18 
software  was  viewed  as  the  glue  that  held 
the  hardware  elements  together.  Because  of 
this  tightly  integrated  system,  changes  to 
the  software  in  one  or  more  of  its  comput¬ 
ers  can  effect  a  major  improvement  in  the 
aircraft’s  capabilities  without  requiring 
hardware  or  airframe  modifications  to  the 
aircraft.  For  example,  adding  a  new 
weapons  system  to  the  aircraft  inventory 
rarely  requires  hardware  modifications. 
Changing  the  software  is  much  easier  and 
faster  than  changing  the  hardware,  shorten¬ 
ing  the  time  required  to  integrate  the 
weapon  on  the  aircraft. 

A  basic  hardware  infrastructure  is, 
however,  necessary  to  provide  the  ability 
to  take  advantage  of  the  F/A-18’s  repro¬ 
grammability.  A  standard  language  for 
communicating  between  processors 
allows  new  weapons  to  be  added  to  the 
inventory  without  requiring  a  hardware 


change  to  the  aircraft.  Just  as  faster 
processor  upgrades  are  necessary  to  sup¬ 
port  expansion  of  software  applications, 
the  F/A-18  transitioned  to  faster  proces¬ 
sors  so  that  smart  weapons  can  exchange 
more  complex  data  in  less  time. 

Operation  Iraqi  Freedom 

As  good  as  F/A-18  operations  were  in 
Desert  Storm,  there  was  plenty  of  room 
for  improvement.  As  of  May  1999, 
Hornet  pilots  had  accumulated  more  than 
3.7  million  flight  hours  and,  in  the  process, 
established  new  records  daily  in  safety, 
reliability,  maintainability,  and  mission  per¬ 
formance  [1]. 

Primarily  due  to  multiple  software 
updates,  the  aircraft  in  Operation  Iraqi 
Freedom  have  significantly  more  combat 
capability.  The  most  dramatic  is  the  intro¬ 
duction  of  a  family  of  new  global  posi¬ 
tioning  system  (GPS) -guided  munitions. 
The  Joint  Direct  Attack  Munition  (JDAM) 
and  JSOW  allow  autonomous  and  highly 
accurate  weapons  delivery  in  all  types  of 
weather.  GPS-guided  weapons  improve  the 
lethality  of  the  F/A-18  weapon  system 
over  the  laser-guided  and  ballistic  weapons 
used  in  Desert  Storm,  which  required  clear 
air  to  be  effective. 

Additionally,  there  was  a  host  of  other 
weapon  improvements.  Some  improve¬ 
ments  were  made  within  the  weapons’  soft¬ 
ware  and  others  within  the  F/A-18’s 
processors  to  enhance  data  exchange 
between  the  weapon  and  aircraft. 

The  F/A-18  aircraft’s  source  lines  of 
code  now  exceed  8.3  million  versus  less 
than  one  million  in  1987.  In  Desert  Storm, 
a  specific  mode  within  a  given  subsystem 
did  not  share  data  with  other  modes  or,  put 
another  way,  the  data  within  a  given  func¬ 
tion  was  separate.  For  example,  the  radar 
would  lose  the  data  from  multiple  air-to-air 
tracks  generated  in  track- while- scan  mode 
when  commanded  to  switch  to  single-tar¬ 
get-track. 

Since  Desert  Storm,  software  updates 
have  been  developed  and  fielded  to  retain 
data  from  the  previous  mode  when 
switching  from  one  mode  to  another.  The 
significance  of  exchanging  data  between 
subsystems  was  identified  and  software 
upgrades  incorporated  to  establish  con¬ 
nectivity  between  the  various  subsystems. 
For  example,  software  was  used  to 
exchange  information  between  the  radar 
and  the  weapon  control  computer.  By 
Operation  Iraqi  Freedom,  we  had  taken  a 
quantum  leap  forward  sharing  data 
between  air,  sea,  and  ground  forces.  Now 
one  source  can  take  a  picture  of  the  target, 
share  that  data  with  an  F/A-18  loaded 
with  the  desired  ordnance,  and  pass  on  the 
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coordinates  and  other  information  for 
rapid,  precise  targeting. 

Today,  the  same  core  set  of  weapons 
used  in  Desert  Storm  is  now  capable  of 
being  redirected  to  a  different  target  during 
flight.  The  efficiency  and  effectiveness  of 
the  weapons  were  increased  through  minor 
upgrades  to  software.  Our  ability  expanded 
from  delivering  multiple  weapons  on  a  sin¬ 
gle  target  to  delivering  multiple  weapons 
on  multiple  targets. 

Navigation  was  dramatically  improved 
with  the  introduction  of  GPS  and  digital 
moving  maps  in  the  F/A-18s.  These  addi¬ 
tions  improved  situational  awareness  and 
sustained  higher  accuracy  than  the  older 
inertial  platform  used  in  Desert  Storm. 

Operation  Iraqi  Freedom  shifted  the 
focus  of  combat.  Our  situational  aware¬ 
ness  expanded  from  focusing  on  a  single 
F/A-18  mission  and  its  intended  targets  to 
all  forces  (ground,  air,  weapon)  coming 
together  to  achieve  a  single  mission  in  a 
coordinated  manner.  Coordination  at  this 
level  required  rapid  and  accurate  identifica¬ 
tion  of  forces. 

The  ability  to  quickly  determine  friend¬ 
ly  from  hostile  contact  was  inherent  to  per¬ 
forming  assigned  tasks.  Timely  informa¬ 
tion  exchange  among  the  Navy,  Air  Force, 
Marines,  Army,  and  coalition  forces  using 
common,  easily  understandable  formats  is 
the  core  element  in  our  most  recent  de¬ 
ployment.  First  deployment  of  systems  like 
the  Digital  Communication  Set  and 
Multifunctional  Information  Distribution 
System  onboard  the  F/A-18  brought  the 
battleforce  commander  the  ability  to  flex 
the  plan  based  on  current  information  re¬ 
garding  target  location,  status,  and  lethality. 

Future  Growth 

By  1991,  it  was  becoming  clear  that  avion¬ 
ics  cooling,  electrical,  and  space  constraints 
would  begin  to  limit  future  growth  of  the 
F/A-18  C/D.  The  multi-mission  F/A-18 
E/F  Super  Hornet  strike  fighter  is  an  up¬ 
grade  of  the  combat-proven  F/A-18  C/D. 

From  an  interoperable,  total  ownership 
cost  viewpoint,  the  biggest  advance  is 
achievement  of  a  90  percent  commonality 
of  avionics  between  the  C/D  and  E/F 
models.  However,  the  F/A-18  E/F  cockpit 
features  a  touch-sensitive,  upfront  control 
display;  a  larger,  liquid-crystal  multipur¬ 
pose  color  display;  and  a  new  engine  fuel 
display.  The  F/A-18  E/F  aircraft  are  4.2 
feet  longer  than  earlier  Hornets,  have  a  25 
percent  larger  wing  area,  and  carry  33  per¬ 
cent  more  internal  fuel  that  will  effectively 
increase  mission  range  by  41  percent  and 

®  The  Capability  Maturity  Model  is  registered  in  the  U.S. 

Patent  and  Trademark  Office  by  Carnegie  Mellon 
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endurance  by  50  percent. 

The  Super  Hornet  incorporates  two 
additional  weapon  stations.  This  allows  for 
increased  payload  flexibility  by  mixing  and 
matching  air-to-air  and/or  air-to-ground 
ordnance.  The  aircraft  can  carry  the  com¬ 
plete  complement  of  smart  weapons, 
including  the  newest  joint  weapons  such  as 
JDAMandJSOW 

Enabling  Technologies  and 
Processes 

When  the  F/A-18  concept  was  first  devel¬ 
oped,  software  was  an  art  rather  than  the 
science  it  is  today.  The  engineering  disci¬ 
pline  has  matured  and  expanded  to 
include  a  systems  view  and  commonly 
accepted  process  principles  as  contained 
in  the  Capability  Maturity  Model®. 
Predictable  product  delivery  containing 
promised  high-quality  functionality  within 
cost  is  the  foundation  of  process 
improvement  models. 

“The  reality  is 
that  software  is  the 
enabler  that  ties 
individual  units  of  a 
battlegroup  into 
a  single  striking  entity.” 


The  F/A-18  was  the  Navy’s  first  tacti¬ 
cal  jet  aircraft  to  incorporate  a  digital,  mul¬ 
tiplex  bus  architecture  for  the  entire  sys¬ 
tem’s  avionics  suite.  The  benefit  of  this 
design  feature  is  that  the  F/A-18  has  been 
relatively  easy  to  upgrade  on  a  regular, 
affordable  basis.  The  software  architecture 
provides  the  basis  for  making  more  fre¬ 
quent  updates  to  system  capabilities  [4]. 

Achieving  an  integrated  system  solu¬ 
tion  demands  communication  and  coordi¬ 
nation  between  the  end  user,  requirements 
personnel,  system  and  software  designers, 
and  test  personnel,  which  has  manifested 
itself  in  adoption  of  Integrated  Product 
Teams  to  move  from  concept  through 
development  to  product  support.  Today’s 
expectations  are  for  a  flexible  system  solu¬ 
tion  that  meets  demands  of  any  current 
combat  situation  while  continuously  for¬ 
mulating  options  for  the  future.  Current 
expectations  assume  a  solid  foundation  of 
individual  software  components  working 
seamlessly  together  to  provide  needed 
capabilities,  not  unlike  the  way  we  expect 
our  laptop  to  perform  needed  functions  at 
any  time,  every  time. 


The  advent  of  new  high-order  pro¬ 
gramming  languages  brings  many  benefits 
to  the  software  development  arena.  The 
complexity  of  needs  that  can  be  addressed 
through  software  algorithms  and  process¬ 
ing  is  huge  compared  to  just  10  years  ago. 
The  new  Super  Hornets  utilize  the  more 
modular,  object-oriented  design  features 
that  did  not  exist  when  the  original  F/A- 
18s  were  rolling  off  the  production  line. 
Basically,  what  took  the  Navy  20  years  to 
create  as  functionality  for  the  F/A-18  air¬ 
craft  was  converted  to  the  more  cost-effec¬ 
tive  High  Order  Language  (HOL)  in  five 
years  with  every  warfighting  function  veri¬ 
fied  in  two  years.  This  recoding  of  func¬ 
tionality  involved  some  1 .3  million  lines  of 
code.  The  effort  involved  delivery  of  more 
than  100  major  warfighting  capabilities 
(e.g.,  HUD,  backup  mode),  containing  well 
over  1,000  possible  operator  selections. 
The  F/A-18  Advanced  Weapons  Lab  was 
recognized  with  the  2003  U.S. 
Government’s  Top  5  Quality  Software 
Projects  award  for  the  HOL  conversion. 

Commercial  off-the-shelf  (COTS) 
products  are  major  enablers  in  converting 
to  HOL.  Our  COTS-based  system  is  the 
enabler  for  future  capability  enhancements 
to  the  F/A-18  production  line.  It  enables 
the  F/A-18  platform  to  grow  and  adds 
more  computing  horsepower  on  demand, 
for  example,  to  expand  the  F/A-18’s  use 
from  its  current  fighter/  attack  role  into  an 
electronic  attack  (EA)  role  currently  pro¬ 
vided  by  the  Navy’s  EA-6B  aircraft.  The 
combination  of  COTS  and  HOL  has  made 
updating  the  aircraft’s  entire  functionality 
more  modular,  economical,  and  faster. 

The  tools  available  to  develop  software 
have  undertaken  unimaginable  leaps  to  sup¬ 
port  integrated  teaming  across  geographi¬ 
cally  diverse  locations.  Even  the  tools  used 
to  generate  software  code  have  become 
more  sophisticated  and  visual,  making  the 
effort  required  to  design  and  perform  low- 
level  testing  more  cost  efficient.  The  F/A- 
1 8  program  uses  commercial  tool  suites  for 
software  development.  Examples  include 
the  desktop  environment  that  allows  devel¬ 
oper  testing  to  occur  on  a  workstation  ver¬ 
sus  a  separate  test  facility.  Another  innova¬ 
tion  was  an  automatic  display  code  genera¬ 
tor  that  shows  promising  use  in  flight  sim¬ 
ulations,  test  facilities,  trainers,  and  techni¬ 
cal  publications. 

Long  before  Operation  Iraqi  Freedom, 
the  tide  had  turned  from  just  looking  at 
what  software  processing  could  be 
achieved  within  a  single  mode,  a  single  box, 
or  even  a  single  F/A-18.  The  battlegroup  is 
turning  into  a  single- striking  unit  making  it 
difficult  to  look  back  and  focus  on  high¬ 
lighting  the  software  aspect  of  this  amazing 
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evolution.  We  now  realize  our  perception 
in  the  1980s  was  that  software  was  the  end 
of  the  journey.  The  reality  is  that  software 
is  the  enabler  that  ties  individual  units  of  a 
battlegroup  into  a  single  striking  entity. 

The  F/A-18  program  understands  - 
and  eagerly  steps  forward  to  engage  in  — 
the  possibilities  of  net-centric  warfare.  The 
full  potential  of  force  multiplication  relying 
on  software  is  still  to  come;  our  most 
recent  combat  test  with  F/A-18  confirms 
the  validity  of  our  mission  and  software 
strategy.  ♦ 
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Web  Sites 


Object  Management 
Group 

www.omg.org 

The  Object  Management  Group  (OMG) 
is  an  open  membership,  not-for-profit 
consortium  that  produces  and  maintains 
computer  industry  specifications  for 
interoperable  enterprise  applications. 
Membership  includes  virtually  every 
large  company  in  the  computer  industry, 
and  hundreds  of  smaller  ones.  Most  of 
the  companies  that  shape  enterprise  and 
Internet  computing  today  are  represented 
on  the  OMG  board  of  directors.  The 
OMG  flagship  specification  is  the  multi¬ 
platform  Model  Driven  Architecture 
(MDA),  recently  under  way  but  already 
well  known  in  the  industry  The  Object 
Management  Architecture  defines  stan¬ 
dard  services  that  will  carry  over  into 
MDA  work.  The  OMG  task  force  stan¬ 
dardizes  domain  facilities  in  industries 
such  as  health  care,  manufacturing, 
telecommunications,  and  more. 

Global  Information  Grid 
Enterprise  Services 

http://ges.dod.mil 

The  Global  Information  Grid  Enterprise 
Services  (GIG  ES)  is  a  suite  of  value- 
added  information,  Web,  and  computing 
capabilities  that  will  improve  user  access 
to  mission-critical  data.  GIG  ES  will  pro¬ 
vide  access  -  anytime,  anywhere  -  to  reli¬ 
able,  decision-quality  information 
through  the  use  of  cutting-edge,  Web- 
based,  networked  services.  GIG  ES 
improves  access  to  reliable  decision-qual¬ 
ity  information  for  Department  of 
Defense  components  at  all  echelons.  End 
users  can  pull  mission-tailored  informa¬ 
tion  intelligently  from  anywhere  within 
the  network  environment  with  minimal 
latency  This  will  enable  leveraging  of 
best-of-breed  concepts  (many  of  them 
Web-based)  and  will  maximize  the  net- 
centric  performance  of  the  GIG  ES. 

Defense  Information 
Systems  Agency 

www.disa.mil 

The  Defense  Information  Systems 
Agency  (DISA)  is  a  combat  support 
agency  that  is  responsible  for  planning, 
engineering,  acquiring,  fielding,  and  sup¬ 
porting  global  net-centric  solutions  and 
operating  the  Defense  Information 
System  Network  to  serve  the  needs  of  the 
president,  vice  president,  the  secretary  of 
defense,  and  the  other  Department  of 


Defense  components,  under  all  condi¬ 
tions  of  peace  and  war.  DISA’s  core  mis¬ 
sion  areas  include  communications,  com¬ 
bat  support  computing,  information 
assurance,  joint  command  and  control, 
and  joint  interoperability  support. 

DACS  and  DSC  Web  Site 

www.dacs.dtic.mil 

The  Defense  Acquisition  Contract 
Service  (DACS)  and  Defense  Software 
Collaborators  (DSC)  Web  site  aids  in  dis¬ 
covering  Department  of  Defense  (DoD)- 
sponsored  software  resources  for  program 
managers  and  software  developers.  The 
DACS  has  been  designated  as  the  DoD 
Software  Information  Clearinghouse  serv¬ 
ing  as  an  authoritative  source  for  state-of- 
the-art  software  information  offering 
technical  services  designed  to  support  the 
development,  testing,  validation,  and 
transitioning  of  software  engineering 
technology.  The  DACS  has  created  the 
DACS  Gold  Practice  Web  site  at  <www. 
GoldPractices.com>  to  provide  informa¬ 
tion  about  many  prevalent  software  acqui¬ 
sition  and  development  best  practices  that 
may  have  a  positive  impact  on  program 
risks  and  return  on  investment. 

Federation  of  American 
Scientists 

www.fas.org 

The  Federation  of  American  Scientists 
(FAS)  conducts  analysis  and  advocacy  on 
science,  technology  and  public  policy 
including  national  security  nuclear 
weapons,  arms  sales,  biological  hazards, 
secrecy  education  technology  informa¬ 
tion  technology  energy  and  the  environ¬ 
ment.  The  FAS  is  a  privately  funded  non¬ 
profit  policy  organization  whose  Board  of 
Sponsors  includes  38  of  Americas  Nobel 
laureates  in  the  sciences. 

American  Institute  of 
Aeronautics  and 
Astronautics 

www.aiaa.org 

Today  with  more  than  31,000  members, 
the  American  Institute  of  Aeronautics 
and  Astronautics  is  the  worlds  largest 
professional  society  devoted  to  the 
progress  of  engineering  and  science  in 
aviation,  space,  and  defense.  The 
Institute  continues  to  be  the  principal 
voice,  information  resource,  and  publish¬ 
er  for  aerospace  engineers,  scientists, 
managers,  policy  makers,  students  and 
educators. 
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Tomahawk  Cruise  Missile  Control: 
Providing  the  Right  Tools  to  the  Warfighter 


Marcus  Urioste 
Lockheed  Martin  Integrated  Systems  &  Solutions 

With  fast-changing  targets ;  unconventional  enemies ;  and  shadowy \  pop-up  targets  of  opportunity,  our  wa  fighters  require  the  very 
best  software  solutions  that  take  advantage  of  newest-generation  cruise  missile  capabilities.  The  Tactical  Tomahawk  Weapon 
Control  System  gives  the  United  States'  and  the  United  Kingdom's  naval  warfighters  the  right  tools  to  carry  out  today's  demanding 
strike  missions. 


The  evening  news  program  cuts  to  a 
videotape  of  a  lone  warship  operating 
off  a  coastline  far  from  home  . . .  the  night 
sky  is  pierced  by  the  brilliant  flash  of  a 
cruise  missile  emerging  from  the  warship’s 
flush-mounted  deck  launcher,  climbing, 
banking,  and  quickly  disappearing  over  the 
horizon.  A  few  miles  away,  the  seascape  is 
altered  by  another  cruise  missile  emerging 
from  the  depths,  sent  on  its  way  from  a 
stealthy  nuclear-powered  submarine  lurk¬ 
ing  beneath  the  waves.  The  attack  is  on, 
and  Tomahawk  cruise  missiles  are  the  first 
punch  in  the  opening  salvo. 

Recent  world  events  show  that  the 
United  States  and  its  coalition  partners  are 
being  called  upon  to  use  smart  weapons  in 
both  the  prosecution  of  conflicts  with 
other  nations,  and  increasingly,  in  the  glob¬ 
al  war  on  terrorism.  Smart  weapons  in  gen¬ 
eral  and  cruise  missiles  in  particular  are 
often  the  first  surgical  instruments  of  mil¬ 
itary  power  projection,  focusing  destruc¬ 
tion  only  where  intended  while  limiting  the 
danger  to  our  warfighters. 

Improving  the  Tools 

The  Tactical  Tomahawk  Weapon  Control 
System  (TTWCS)  is  the  next-generation 
system  for  planning  and  controlling 
Tomahawk  cruise  missile  flight.  The 
TTWCS  development  is  part  of  the  U.S. 
Navy’s  Tactical  Tomahawk  Weapon 
System  Upgrade  to  improve  the  flexibility 
and  responsiveness  of  Tomahawk  cruise 
missiles,  add  new  capabilities,  and  upgrade 
existing  fleet  systems. 

The  TTWCS’  efforts  include  the  full 
array  of  system  development,  including 
requirements  definition,  system  engineer¬ 
ing,  system  architecture  and  design,  soft¬ 
ware  development,  software  integration, 
hardware  engineering,  hardware  manufac¬ 
turing,  hardware  and  software  integration, 
system  testing,  logistics,  training,  and  sys¬ 
tem  installation.  The  TTWCS  program 
will  support  U.S.  surface  ships  and  fast- 
attack  submarines,  and  is  planned  for 
newly  converted  U.S.  guided  missile  sub¬ 
marines  and  U.K.  fast- attack  submarines. 


Tools  in  the  Warfighter’s 
Hands 

The  TTWCS  was  formally  approved  for 
initial  operating  capability  in  December 
2003  to  work  with  existing  Tomahawk 
missiles  in  the  nation’s  inventory.  The 
TTWCS  initial  operating  capability  for  the 
newest  Block  IV  Tactical  Tomahawk  mis¬ 
sile  was  achieved  in  mid-2004.  The  U.S. 


“  ...TTWCS  adds  much 
more  capability  to 
control  the  Tomahawk 
missile(s),  direct,  redirect, 
mission  plan,  and  replan, 
while  at  the  same  time 
keeping  the  system 
interfaces  easy  to  use 
for  the  officers  and 
sailors  onboard.” 


Navy  began  fleet  installation  of  the 
TTWCS  system  in  early  2004  and  could 
provide  up  to  one  hundred  new  weapon 
control  systems  by  2008. 

The  Right  Team 

The  TTWCS  program  consists  of  a  multi¬ 
disciplinary  team  (systems  engineers,  soft¬ 
ware  developers,  system  testers,  hardware 
engineers,  and  logistics  and  training  spe¬ 
cialists)  composed  of  the  acquisition 
agent.  Naval  Air  Systems  Command  for 
Cruise  Missile  Weapon  Control  Systems, 
Patuxent  River,  MD;  the  Naval  Surface 
Warfare  Center  Division,  Dahlgren,  VA; 
the  Naval  Undersea  Warfare  Center 
Division,  Newport,  R.I.;  and  the  prime 
contractor,  Lockheed  Martin  Tactical 
Control  Systems,  Valley  Forge,  PA. 


Tomahawk  Command  and 
Control  Legacy 

The  U.S.  Navy’s  Cruise  Missile  Program 
has  been  effectively  evolving  for  almost  30 
years.  The  original  Tomahawk  Weapon 
Control  System  effort  started  in  the  late 
1970s,  and  the  follow-on  Advanced 
Tomahawk  Weapon  Control  System 
(ATWCS)  program  lasted  from  June  1993 
to  December  1998. 

The  ATWCS  was  a  large-scale  hard¬ 
ware  and  software  integration  and  soft¬ 
ware  development  program  to  replace  the 
Tomahawk  cruise  missile  shipboard  oper¬ 
ational  hardware  and  software  system. 
The  ATWCS  team  designed,  developed, 
and  integrated  software  products  from 
commercial  corporations  and  U.S.  Navy 
laboratories  into  a  cohesive,  multi-security 
level  weapons  control  system;  conducted 
system  level  tests  of  the  integrated  prod¬ 
ucts;  prototyped  future  requirements;  and 
successfully  implemented  the  ATWCS  on 
U.S.  Navy  surface  ships  and  submarines. 

Lockheed  Martin  won  a  competitive 
program  to  provide  the  third-generation 
cruise  missile  weapon  control  system,  the 
TTWCS,  in  May  1999. 

Benefits  to  the  Warfighter 

Shortening  the  Timeline 

The  TTWCS  system  will  reduce  the 
warfighter’s  Tomahawk  timeline  by  bring¬ 
ing  the  missile  mission  planning  function 
aboard  the  firing  unit.  Previously,  this 
planning  function  was  done  solely  at 
shore-based  or  dedicated  afloat  cruise 
missile  support  centers,  taking  much  more 
time  to  replan  and  provide  new  or  revised 
missions  to  the  ship. 

The  system’s  Launch  Platform  Mission 
Planning  component  is  a  new  capability 
that  reduces  weapon  system  reaction 
times  by  speeding  up  the  tactical  mission 
planning  process.  Another  new  capability 
is  the  ability  to  redirect  missiles  to  new  tar¬ 
gets  while  in  flight,  available  with  the 
newest  Block  IV  Tomahawk.  These 
newest  capabilities  are  particularly  impor¬ 
tant  today,  with  fast-changing  targets. 
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unconventional  enemies,  and  shadowy, 
pop-up  targets  of  opportunity. 

Ease 

The  new  TTWCS  program  took  on  the 
task  of  providing  the  next-generation 
cruise  missile  weapon  control  system  to 
handle  the  newest  technological  improve¬ 
ments  to  the  Tomahawk  missile,  while 
keeping  the  system  user-friendly  enough 
to  be  maintained  by  young  shipboard 
operators  not  far  removed  from  high 
school  graduation.  Simply  put,  the 
TTWCS  adds  much  more  capability  to 
control  the  Tomahawk  missile(s),  direct, 
redirect,  mission  plan,  and  replan,  while  at 
the  same  time  keeping  the  system  inter¬ 
faces  easy  to  use  for  the  officers  and 
sailors  onboard. 

Space 

Space  on  ships  and  submarines  is  in  great 
demand  by  equipment  to  power  and  pro¬ 
tect  the  ship,  by  weapon  systems,  and  by 
people.  The  TTWCS  successfully  reduced 
the  command-and-control  equipment 
footprint  onboard  from  seven  racks  of 
computer  equipment  to  three,  all  while 
adding  vital  new  capabilities. 

Software’s  Vital  Role  in  the 
TTWCS 

Multiple  Platforms 

The  TTWCS  is  being  installed  or  is  plan¬ 
ning  to  be  installed  on  U.S.  Navy  surface 
ships  (destroyers  and  cruisers),  U.S.  Navy 
converted  guided  missile  submarines,  and 
fast-attack  submarines  (Los  Angeles 
class /Virginia  class/U.K.’s  Trafalgar  and 
Astute  class).  On  U.S.  fast- attack  sub¬ 
marines,  the  TTWCS  runs  on  the  Combat 
Control  System  common  hardware.  The 
TTWCS  surface- ship  environment  con¬ 
sists  of  multiple,  redundant,  single-board 
computers,  running  UNIX  and  Windows 
operating  systems.  The  fully  redundant, 
VME-based  hardware  architecture  is 
housed  in  two  TTWCS  equipment  cabi¬ 
nets.  The  software  is  executed  by  opera¬ 
tors  at  four  tactical  display  consoles  on 
surface  ships  and  from  one  to  four  con¬ 
soles  on  submarines.  The  TTWCS  inter¬ 
faces  with  several  shipboard  systems, 
including  the  inertial  navigation  system, 
weapon  vertical  launch  system,  the  global 
command-and-control  system  —  maritime, 
and  communications  networks. 

The  Right  Software 

The  TTWCS  is  a  major  software-based 
reengineering  upgrade  to  implement  even 

®  CMM  and  CMMI  are  registered  in  the  U.S.  Patent  and 
Trademark  Office  by  Carnegie  Mellon  University. 


greater  warfighter  capability  over  previous 
Tomahawk  missile  control  generations. 
The  program’s  software  development  is 
certified  at  the  Software  Engineering 
Institute’s  Capability  Maturity  Model® 
(CMM®)  Integration  (CMMI®)  Level  5. 
The  software  development  incorporates  a 
variety  of  components  that  spans  new 
development,  reused  software  from  the 
predecessor  ATWCS  program,  and  gov¬ 
ernment  and  commercial  products. 

The  TTWCS  software  consists  of  six 
computer- software  configuration  items 
with  approximately  500,000  lines  of  new 
and  modified  development  code  and 
500,000  lines  of  reused  code.  The  deliv¬ 
ered  software  is  C,  C++,  Java,  and  Ada, 
and  is  developed  to  be  compatible  with 
the  Defense  Information  Infrastructure 
Common  Operating  Environment  (DII 
COE).  The  DII  COE  is  a  Department  of 
Defense-wide  common  operating  envi¬ 
ronment  that  enables  common  standards 

“The  TTWCS  benefits 
from  an  incremental 
software  development 
model  that  offers 
improved  quality, 
reduced  cost,  and  better 
adherence  to  schedule 
over  spiral  or  waterfall 
development/ 9 


and  implementation  tools  for  military  tac¬ 
tical  situational  awareness  and  system 
interoperability.  Prior  to  DII  COE,  each 
new  military  system  requiring  situational 
awareness  and  interoperability  developed 
individual  solutions. 

The  TTWCS  program  reached  a  DII 
COE  Level  7  (8  is  highest  possible),  signi¬ 
fying  virtually  no  duplication  of  DII  COE 
functions  within  the  system  application. 
The  TTWCS  demonstrated  the  benefits  of 
the  DII  COE  reuse  concept  through 
reduction  in  development  and  life- cycle 
costs.  The  DII  COE  software  is  incorpo¬ 
rated  into  the  TTWCS  infrastructure  layer, 
which  minimizes  redundant  code  and 
maximizes  consistency  for  system  services 
and  evolution  to  newer  computing  plat¬ 
forms.  Software  development  is  accom¬ 
plished  using  object-oriented  methodolo¬ 


gies  and  Common  Object  Request  Broker 
Architecture  for  interfaces  among  soft¬ 
ware  components. 

The  Right  Development 
Environment 

The  TTWCS  software  development  envi¬ 
ronment  consisted  of  a  network  of 
Hewlett  Packard  (HP)  workstations  (B- 
180Ls  and  C-llOs)  and  servers  (K-360 
and  K-580  mid-class),  all  running  HP 
UNIX.  Engineers  used  desktop  PCs  to 
access  the  development  network  via 
XOnNet.  Tools  used  include  Popkins’ 
System  Architect  (system/ software  archi¬ 
tecture  design);  Telelogic’s  COOLiJex 
(detailed  software  design);  Telelogic’s 
DOORS  (requirements  traceability); 
IBM’s  ClearCase  (configuration  manage¬ 
ment);  IBM’s  ClearQuest  (problem 
reporting/resolution  database);  HP’s 
SoftBench  (C/C++  compiling  and 
debug);  ADA  Core  Technology’s  GNAT 
(Ada  compiler  and  coding);  and  Aonix’ 
Teleuse  and  Builder  Xcessory  (human- 
computer  interface  display  generation). 

The  Right  Development 
Model 

The  TTWCS  benefits  from  an  incremental 
software  development  model  that  offers 
improved  quality,  reduced  cost,  and  better 
adherence  to  schedule  over  spiral  or 
waterfall  development.  Each  increment 
adds  functionality  and  is  taken  through  a 
full  development  and  test  cycle.  In  soft¬ 
ware  increment  one,  legacy  software  from 
ATWCS  was  integrated  with  TTWCS 
hardware.  During  increment  two,  the 
TTWCS  infrastructure  (Operating 
Environment  and  Common  Services 
Middleware  Layer)  was  implemented  and 
matured.  Software  increments  three 
through  six  added  new  functionality  to  the 
heritage  weapon  control  system.  The  final 
increment  contained  the  full  TTWCS 
functionality  and  was  formally  tested 
under  rigorous  supervision. 

Incremental  software  development 
allows  for  risk  reduction  through  incre¬ 
mental  system  integration.  Each  succes¬ 
sive  increment  is  developed  at  reduced 
technical  risk  due  to  a  solid  functional  and 
performance  foundation  established  in  the 
preceding  increment. 

Software  Metrics 

The  TTWCS  contract  was  awarded  to 
Lockheed  Martin  in  May  1999.  The  U.S. 
Navy  and  Lockheed  Martin  jointly  deter¬ 
mined  that  the  TTWCS  would  be  a  focus 
program  for  implementing  CMM  Level  5 
processes  and  supporting  tools.  In 


September  2004 


www.stsc.hill.af.mil  9 


The  Software  Edge 


December  2000,  the  TTWCS  was  scored 
at  CMM  for  Software  Level  5.  In  June 
2002,  Lockheed  Martin  Management  & 
Data  Systems  (now  Lockheed  Martin 
Integrated  Systems  &  Solutions)  became 
one  of  the  first  companies  in  the  world  to 
achieve  CMMI  Level  5. 

The  implementation  of  Level  5 
processes  on  the  TTWCS  has  resulted  in 
productivity  improvements,  defect  reduc¬ 
tions,  and  cost  savings  for  the  U.S.  govern¬ 
ment.  CMMI  Level  5  has  provided  mea¬ 
surable  improvements  in  software  devel¬ 
opment:  a  30  percent  increase  in  software 
productivity,  a  20  percent  drop  in  develop¬ 
ment  costs,  and  a  15  percent  drop  in 
detect/find/fix  software  cost. 

•  Productivity.  Based  on  historical  met¬ 
rics  for  similar  developments,  using 
CMM  Level  5  processes  resulted  in  a 
reduction  of  over  15,000  development 
hours. 

•  Quality.  In-process  quality  activities 
enabled  early  problem  detection  during 
design  and  code/unit  test,  resulting  in  a 
30  percent  reduction  in  defects  during 
integration  and  verification. 

•  Integrated  Program  Environment 
(IPE)  and  Integrated  Development 
Environment  (IDE).  The  IPE 
enabled  everyone  on  the  program, 
regardless  of  location,  to  participate  in 
daily  decision  making.  The  IDE 
enabled  collaborative  development 
among  500+  users  across  the  United 
States. 

•  DII  COE  Compliance.  The  delivered 
software  achieves  DII  COE  Level  7 
compliance  for  newly  developed  soft¬ 
ware  and  Level  5  for  reused  software. 
The  DII  COE  software  is  incorporated 
into  the  TTWCS  infrastructure  layer, 
which  minimizes  redundant  code  and 
maximizes  consistency  for  system  ser¬ 
vices. 

•  Global  Command-and-Control  Sys¬ 
tem  -  Maritime  Interoperability. 

The  Weapon  Control  System  (WCS) 
Common  Services  minimizes  redun¬ 
dant  code  and  maximizes  consistency 
for  all  system  services  by  using  services 
developed  and  maintained  by  the  U.S. 
Navy. 

Getting  the  Process  Right 

The  TTWCS  benefits  from  high  quality, 
defect  prevention,  improved  productivity, 
and  reduced  risk  inherent  in  achieving  the 
industry’s  highest  level  of  software  process 
maturity.  The  program  also  complies  with 
ISO  9001  objectives.  The  TTWCS  Product 
Assurance  Plan  spans  the  entire  program 
life  cycle  and  ensures  adherence  to  manda¬ 
tory  processes;  development  of  compliant 


software,  hardware,  and  documentation; 
and  application  of  quantitative  manage¬ 
ment  (metrics)  techniques.  The  plan 
applies  to  all  locations  where  program 
activities  occur.  The  plan’s  proactive  prod¬ 
uct  assurance  methodology  encompasses 
the  following: 

•  Preventive  action  and  continuous 
process  improvement. 

•  In-process  inspections  and  process  and 
product  compliance  audits  at  all  sites. 

•  Root-cause  analysis  to  identify  areas 
for  improvement,  increased  product 
quality,  and  reduced  risk. 

•  Metric  collection  and  analysis  to  identi¬ 
fy  areas  for  process  improvement  early 
in  development  and  throughout  the 
entire  life  cycle. 

The  Right  Test  Environment 

Team  Approach 

The  TTWCS  test- approach  leveraged  facil¬ 
ities  and  personnel  located  at  government 
and  contractor  facilities.  This  approach 
allowed  the  team  to  evaluate  and  test  the 
Tomahawk  Weapon  System  from  multiple 
perspectives,  ensuring  a  robust  test  pro¬ 
gram  that  reduced  redundancy  and  validat¬ 
ed  the  system’s  capability  to  meet  the 
warfighter’s  needs.  Finding  problems  early 
and  getting  timely  fleet  feedback  in  the 
development  cycle  reduced  follow-on 
development  costs. 

At-Sea  Testing 

To  support  at-sea  testing  of  the  weapon 
control  system  as  part  of  the  larger 
weapon  system,  the  TTWCS  team  validat¬ 
ed  the  performance  of  all  software  builds 
produced  by  the  WCS  software  develop¬ 
ment  team  prior  to  the  installation  aboard 
the  test  ship,  U.S.S.  Stethem,  an  Arleigh 
Burke  class-guided  missile  destroyer.  The 
team  established  a  configuration  that  per¬ 
mitted  the  U.S.S.  Stethem  to  simulate  com¬ 
munication  with  multiple  Tactical 
Tomahawk  missiles,  thus  enabling  the 
completion  of  the  technical  evaluation 
shipboard  event. 

The  configuration  allowed  testing  of 
high  numbers  of  missile  launches  and  in¬ 
flight  communications,  utilizing  non- 
expended  assets  that  offer  repeatability, 
sustainability,  and  high  accuracy  at  an 
established  one-time  cost  for  procure¬ 
ment  and  low  operational  cost.  The  test 
ship  was  able  to  perform  missile  redirec¬ 
tion  of  multiple  missiles  simultaneously 
and  request  health  and  status  information 
from  the  missiles  during  flight.  The  mis¬ 
sile  simulation  responded  with  both 
scheduled  and  unscheduled  health  and 
status  event  messages  as  directed  by  the 
communications  plan,  resulting  in  a  suc¬ 


cessful  test  event. 

Summary:  Providing  What 
Matters 

The  TTWCS  program’s  success  to  date  in 
providing  the  warfighter  with  the  very  best 
Tomahawk  cruise  missile  control  capabili¬ 
ties  is  a  direct  result  of  the  dedicated  team 
that  stands  behind  this  vital  warfighter  sys¬ 
tem.  Through  a  combination  of  strong 
warfighter  guidance  and  contractor  per¬ 
formance,  adoption  of  industry  best  prac¬ 
tices,  and  the  exercise  of  innovative  tech¬ 
nical  solutions,  the  TTWCS  team  has  pro¬ 
vided  even  more  timely  capabilities  for  the 
warfighter.  Ships  and  submarines  will  have 
cruise  missile  capabilities  that  exceed  even 
the  successful  capabilities  seen  recently  in 
Kosovo,  Afghanistan,  and  Iraq.  In  a  hos¬ 
tile  world  where  a  surgical  strike  can  be 
needed  in  a  moment’s  notice,  the  TTWCS 
team  has  provided  the  capability  that  gives 
our  warfighters  exceptional  flexibility,  ver¬ 
satility,  and  timeliness  to  address  threats  to 
our  nation.  ♦ 
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This  article  presents  an  architecture  modeling  approach  for formulating  service-oriented  architectures  such  as  those  being  devel¬ 
oped  on  the  global  information  grid.  The  approach  uses  object-oriented  techniques  to  supplement  the  traditional  Command \ 

Control,  Communications,  Computers,  Intelligence,  Surveillance,  and  Reconnaissance  Tramework. 


The  global  information  grid  (GIG)  is 
the  globally  interconnected,  secured, 
end-to-end  set  of  information  capabili¬ 
ties,  associated  processes,  and  personnel 
for  collecting,  processing,  storing,  dissem¬ 
inating,  and  managing  information  on 
demand  to  warfighters,  policy  makers,  and 
support  personnel  [1].  The  GIG  supports 
all  U.S.  Department  of  Defense  (DoD), 
national  security,  and  related  intelligence 
community  missions  and  functions.  It 
provides  capabilities  from  all  operating 
locations  and  interfaces  to  coalition, 
allied,  and  non-DoD  users  and  systems. 

The  GIG  as  a  transformational  vision 
aims  at  achieving  information  superiority 
in  a  network-centric  environment.  It 
enables  various  systems  to  interoperate 
with  each  other.  For  the  warfighters,  it 
brings  power  to  the  edge  through  a  Task, 
Post,  Process,  Use  process.  For  the  busi¬ 
ness  and  intelligence  communities,  it  pro¬ 
vides  the  infrastructure  for  effective 
information  gathering  and  collaborative 
operation. 

This  transformation  from  a  central¬ 
ized,  sequential  thinking  and  a  static  one- 
to-one  interfacing  paradigm  to  a  distrib¬ 
uted,  parallel  information  sharing  and 
dynamic  collaboration  approach  requires 
a  fundamental  shift  in  the  way  systems  are 
built.  Specifically,  it  lends  itself  to  a  ser¬ 
vice-oriented  architecture  (SOA)  on  a 
ubiquitous  network  carrying  information 
on  demand. 

In  an  SOA,  a  set  of  loosely  coupled 
services  works  together  seamlessly  and 
securely  over  a  network  to  provide  func¬ 
tionalities  to  end  users.  These  services 
have  well-defined  interface  contracts. 
Supported  by  service  management  tools 
at  the  enterprise  level,  they  are  published, 
discovered,  mediated,  and  consumed  in 
an  orderly  fashion. 

The  service-oriented  approach  is 
inherently  dynamic.  It  allows  fast  forma¬ 
tion  of  expedient  communities  of  interest 
(COI)  to  handle  highly  volatile  situations 
and  changing  mission  requirements.  It 
also  supports  the  stable  operation  of 
longstanding  or  institutional  COIs.  The 
SOAs  are  flexible  because  each  service 


encapsulates  the  underlying  platforms 
and  technologies  that  support  it.  The  ser¬ 
vices  provided  at  the  enterprise  level  are 
therefore  agnostic  to  those  specific  plat¬ 
forms  and  technologies. 

The  Command,  Control,  Communi¬ 
cations,  Computers,  Intelligence,  Surveil¬ 
lance,  and  Reconnaissance  (C4ISR) 
Architecture  Framework  [2],  along  with 
its  three  standard  views  and  common 
products,  has  been  widely  used  in  building 
C4ISR  systems.  The  framework  was  orig¬ 
inally  developed  in  1996  by  the  DoD  to 


“In  an  SOA 
[service-oriented 
architecture],  a  set  of 
loosely  coupled  services 
works  together 
seamlessly  and  securely 
over  a  network  to 
provide  functionalities  to 
end  users.  These  services 
have  well-defined 
interface  contracts.” 


provide  guidance  for  describing  architec¬ 
tures.  Version  2  was  officially  mandated  in 
1998  as  the  DoD  Architectural  Frame¬ 
work  and  is  being  superceded  by  the  DoD 
Architecture  Framework  (DoDAF). 
Standard  techniques  employed  by  C4ISR 
include  point-to-point  interfacing,  static 
connectivity,  and  data-flow  analysis. 
These  are  more  suited  to  the  traditional 
sequential  processing,  system-oriented, 
and  one-to-one  integration  paradigm. 

With  the  ongoing  efforts  to  transform 
the  DoD  into  a  network-centric,  service- 
oriented  environment,  the  following 


questions  are  often  raised: 

•  Does  the  C4ISR  framework  apply  to 
such  a  service-oriented  architecture? 

•  How  is  it  supplemented  with  other 
techniques  to  fully  describe  such 
architectures? 

•  What  are  the  set  of  products  that 
describe  the  essence  of  a  service-ori¬ 
ented  architecture? 

Whereas  full  answers  to  these  ques¬ 
tions  will  require  extensive  discussion, 
this  article  describes  a  pragmatic  ap¬ 
proach  that  naturally  fits  the  service-ori¬ 
ented  environment.  This  approach  uti¬ 
lizes  object-oriented  design  and  analysis 
techniques  to  supplement  the  standard 
C4ISR  framework  for  developing  SOAs. 
As  the  DoD  moves  toward  a  network¬ 
centric  environment  supported  by  SOAs, 
this  approach  provides  a  timely  and  rigor¬ 
ous  methodology  for  specifying  future 
enterprise  architectures,  and  has  been 
recently  applied  to  the  architecture  devel¬ 
opment  of  Net-Centric  Enterprise 
Services  (NCES)  with  satisfactory  results. 

The  NCES  is  a  collaborative  environ¬ 
ment  that  supports  vertical/horizontal 
interoperability  between  DoD  business 
and  warfighting  domains,  as  well  as  the 
national  intelligence  domain  [3].  The 
NCES  provides  the  core  enterprise  ser¬ 
vices  that  support  various  standing  and 
expedient  COIs  on  the  GIG. 

Using  this  approach,  the  use  cases  for 
the  NCES  core  enterprise  services  were 
developed.  The  corresponding  opera¬ 
tional  and  systems  views  were  construct¬ 
ed  as  part  of  an  integrated  architecture 
product.  Activities  in  the  use  cases  were 
also  mapped  to  the  Net-Centric  Opera¬ 
tions  and  Warfare  Reference  Model  [4] . 

In  the  following  sections,  I  first 
describe  the  approach  for  formulating  an 
SOA.  Using  an  enterprise  messaging  sys¬ 
tem  as  an  example,  I  then  discuss  the  cor¬ 
responding  architecture  views  that 
embody  the  approach  in  the  C4ISR 
framework1. 

Formulating  an  SOA 

In  formulating  an  SOA,  you  start  with 
operation.  Here  the  focus  is  how  end 
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A  rch  itectu  re  V  ie w  s  and  Products 

The  Department  of  Defense  (DoD)  Architecture  Framework  (AF)  (which  will  supercede 
the  Command,  Control,  Communications,  Computers,  Intelligence,  Surveillance,  and 
Reconnaissance  Architecture  Framework)  provides  the  guiding  principles  for  modeling 
and  designing  architectures  in  the  DoD  environment  (Version  One  is  available  at 
<www.aitcnet.org/dodfw>).  Architecture  is  described  by  three  views: 

•  The  Operational  View  (OV):  Describes  the  tasks,  activities,  operational  elements, 
and  information  exchanges  required  to  accomplish  missions. 

•  The  Systems  View  (SV):  Describes  systems  and  interconnections  supporting  oper¬ 
ational  functions. 


•  The  Technical  View  (TV):  Includes  technical  standards,  implementation  conven- 


tions,  rules,  and  criteria  that  guide  systems  implementation. 

Each  view  has  a  set  of  products.  Some  are  listed  in  the  table  below  (the  product  num¬ 
bers  do  not  imply  the  order  of  developing  them).  In  addition  to  those  listed,  there  are 
12  products  and  two  All  Views  products  omitted  for  brevity. 

Views 

Products  and  Descriptions 

Operational 

OV-1  (high-level  operational  concept  graphic) 

OV-2  (operational  node  connectivity  description) 

OV-3  (operational  information  exchange  matrix) 

OV-5  (operational  activities  model) 

OV-6c  (operational  event-trace  description) 

Systems 

SV-1  (systems  interface  description) 

SV-2  (systems  communications  description) 

SV-4  (systems  functionality  description) 

SV-5  (operational  activity  to  systems  function  traceability  matrix) 
SV-6  (system  data  exchange  matrix) 

SV-11  (physical  schema) 

Technical 

TV-1  (technical  standards  profile) 

users,  systems,  or  applications  use  ser¬ 
vices.  Use  cases  in  Unified  Modeling 
Language  (UML)  [5]  describe  the  external 
behavior  of  a  service  as  seen  or  utilized 
by  an  actor  (user,  system,  or  application). 
The  boundary  of  the  service  in  a  use  case 
is  clearly  delineated.  The  interaction  of 


Figure  1:  Formulating  an  SOA 


Figure  2:  Use  Cases  as  Fart  of  the  Activity 
Model  (OVA)  for  the  Enterprise  Messaging 
System 


the  actor  with  the  service  is  described 
without  revealing  the  internal  details  of 
the  service.  Use  case  is,  therefore,  a  nat¬ 
ural  tool  for  describing  operational  activ¬ 
ities  in  an  SOA. 

Based  on  the  operational  concept,  the 
scope  of  services,  and  the  high-level 
requirements,  one  may  identify  a  set  of 
high-level  critical  use  cases.  These  are  the 
use  cases  that  the  architecture  must  sup¬ 
port  to  meet  the  minimal  requirements. 
Use  cases  are  not  requirements. 
Nevertheless,  they  illustrate  what  func¬ 
tions  architecture  provides  and  highlight 
the  requirements.  Therefore,  use  cases  are 
the  first  step  in  formulating  an  SOA  (see 
Figure  1). 

In  each  use  case,  typically  two  or  more 
nodes  interact  with  each  other  by 
exchanging  information.  If  a  node  is  a 
service  consumer,  then  it  is  an  actor  in 
the  use  case  for  that  service.  If  it  is  a 
provider,  then  it  is  a  component  provid¬ 
ing  that  service.  Traditionally,  a  node  in 
the  C4ISR  framework  represents  a  role, 
an  organization,  an  operational  facility, 
etc.  For  an  SOA,  its  scope  is  expanded  to 
include  shared  resources  and  services. 
Hence  a  service  node  interacts  with  con¬ 
sumer  nodes  to  provide  services.  Use  case 
and  node  are,  therefore,  the  primary 
objects  in  describing  the  operational 


aspects  of  an  SOA,  as  shown  in  Figure  1 . 

Once  the  operational  aspects  are  iden¬ 
tified,  the  next  action  is  to  find  the  solu¬ 
tion  that  satisfies  the  operational  require¬ 
ments.  In  an  SOA,  each  service  provides 
a  set  of  well-defined  functions  useful  to 
its  users,  or  consumers.  An  example  is 
chat  service,  which  allows  users  to  per¬ 
form  online  chat.  A  set  of  services  may 
interact  in  an  orderly  manner  to  provide  a 
complete  set  of  mission  functions.  In  this 
way  they  form  a  mission  application,  or 
simply  application.  Application  is  not  just 
a  simple  collection  of  services,  but  an 
integral  set  of  logically  connected  ser¬ 
vices.  Application  and  service  form  the 
primary  objects  that  describe  the  systems 
aspects  of  an  SOA.  They  are,  in  practice, 
the  software  that  needs  to  be  built  by 
developers. 

Finally,  standards  and  technologies  are 
the  primary  objects  that  constitute  the 
technical  foundation  in  implementing  an 
SOA.  Figure  1  summarizes  the  approach 
for  formulating  an  SOA,  along  with  the 
primary  objects.  Discussed  next  are  the 
corresponding  architecture  views  that 
embody  the  approach  in  the  C4ISR 
framework1. 

Operational  View 

For  a  concrete  example,  let  us  consider  an 
enterprise  messaging  system,  which 
encompasses  e-mail,  instant  messaging 
(IM),  chat,  and  presence  services.  The 
critical  use  cases  are  send  and  receive  e- 
mails  and  instant  messages,  participate  in 
a  chat  session,  subscribe  to  and  receive 
presence  notifications,  etc.  They  are 
shown  in  the  use  case  diagram  in  Figure 
2.  In  addition,  the  administrator  config¬ 
ures  and  administers  the  services. 

For  each  use  case,  you  may  describe  a 
sequence  of  events  or  activities.  These 
activities  may  be  presented  in  a  hierarchy, 
as  in  the  standard  activity  model  opera¬ 
tional  view  (OV-5).  Here,  however,  the 
use  cases  provide  a  natural  grouping  of 
those  related  activities.  Additionally,  a  use 
case  highlights  the  actors  and  system/ ser¬ 
vice  boundary,  allowing  you  to  delineate 
roles  and  nodes  easily.  Hence,  include  use 
case  as  part  of  OV-5  and  consider  it  an 
essential  product  for  an  SOA. 

For  an  SOA,  the  use-case  diagrams 
(such  as  Figure  2)  often  identify  the 
nodes.  These  nodes  are  roles,  organiza¬ 
tions,  shared  resources,  or  service  nodes. 
You  can  further  draw  the  connections 
(i.e.,  the  need  lines)  between  the  nodes, 
thereby  forming  the  operational  node 
connectivity  description  (OV-2).  An 
example  is  given  in  Figure  3.  Except  for 
the  use  of  UML  deployment  diagram 
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notations,  this  figure  is  the  same  as  the 
standard  OV-2. 

Finally,  a  description  of  each  connec¬ 
tion  in  Figure  3  gives  the  operational 
information  exchange  matrix  (OV-3). 
Each  row  in  the  matrix  describes  the 
provider  and  consumer  nodes,  the  infor¬ 
mation  exchange,  the  mode  of  exchange 
(e.g,  synchronous),  the  security  aspect, 
etc.  This  again  is  the  same  as  the  standard 
OV-3. 

The  high-level  operational  concept 
graphics  (OV-1)  still  applies  to  an  SOA. 
This,  together  with  OV-5,  OV-2,  and  OV- 
3,  encompasses  the  concepts  of  opera¬ 
tion,  the  use  cases  from  user’s  viewpoint, 
the  connectivity  between  operational 
nodes,  and  their  information  exchanges. 
They  therefore  characterize  the  essential 
operational  aspects  of  an  SOA. 
Furthermore,  since  operational  nodes 
include  shared  resources  and  services, 
dynamic  and  collaborative  operational 
activities  are  properly  captured. 

To  analyze  more  details  in  the  use 
cases,  you  may  use  the  Integration 
Definition  for  Function  Modeling 
process  diagrams  [6]  to  depict  the  activi¬ 
ties  (including  inputs,  controls,  outputs, 
and  mechanisms).  This  will  also  be  part 
of  OV-5.  Alternatively,  you  can  use  the 
UML  sequence  diagrams  (OV-6c)  to 
describe  the  details. 

Systems  View 

As  discussed  earlier,  application  and  ser¬ 
vice  are  the  primary  objects  in  Systems 
View  (SV).  In  an  SOA,  one  is  more  con¬ 
cerned  with  the  logical  interaction 
between  service  providers  and  con¬ 
sumers.  Rather  than  relying  on  static  con¬ 
nections,  users  in  an  SOA  may  select  dif¬ 
ferent  services  under  different  use  cases. 
Consequently,  system  interface  descrip¬ 
tion  (SV-1)  in  the  form  of  logical  archi¬ 
tecture  diagrams  is  usually  appropriate. 
Logical  architecture  diagrams  show  the 
connectivity  between  service  provider 
nodes  (or  components)  and  consumer 
nodes.  They  also  specify  the  types  of 
interface  or  communication  protocols. 

For  efficient  software  management, 
closely  related  use  cases  utilizing  similar 
services  are  usually  grouped  together  and 
supported  by  an  application.  Thus  you 
may  draw  a  functional  decomposition 
diagram  as  systems  functionality  descrip¬ 
tion  (SV-4).  The  diagram  will  identify  the 
applications.  Each  application  supports 
one  or  more  use  cases  and  may  have  a 
corresponding  logical  architecture  dia¬ 
gram  as  SV-1. 

Going  back  to  the  sample  enterprise 
messaging  system,  the  basic  services  are 


e-mail,  IM,  chat,  and  presence  services. 
E-mail  service  is  a  familiar  form  of  asyn¬ 
chronous  messaging  and  may  be  provided 
through  either  a  thick  or  thin  client.  The 
other  three  services  emphasize  synchro¬ 
nous  interaction  and  therefore  are  best 
provided  through  a  single  application  to 
the  users.  The  corresponding  systems 
functionality  description  (SV-4)  is  shown 
in  Figure  4. 

The  SV-1  picture  for  the  e-mail  ser¬ 
vice  is  shown  in  Figure  5.  Here  again, 
notations  similar  to  the  UML  deployment 
diagrams  are  used.  The  boxes  represent 
nodes  that  are  connected  by  channels  of 
data  exchange.  A  service  node  has  a  well- 
defined  service  interface  (indicated  by  a 
protruded  match  head)  and  supports  data 
exchange  in  certain  protocols.  In  Figure 
5,  the  protocols  and  interfaces  are 
HyperText  Markup  Language  (HTML), 
HyperText  Transfer  Protocol  (Secured) 
(HTTPS),  Simple  Mail  Transfer  Protocol 
(SMTP),  Internet  Message  Access 
Protocol  (IMAP),  and  the  mail  access 
application  programming  interface  called 
Post  Office  Protocol  v.3  (POP3). 

Services  are  often  organized  into  layers, 
with  the  lowest  layer  containing  core  ser¬ 
vices,  and  the  upper  layers  containing 
value-added  and  composite  services. 
Services  in  the  upper  layers  use  those  in  the 
lower  ones  to  perform  specific  functions. 
You  may  use  service  layer  diagrams  such  as 
SV-1  to  show  the  dependencies  of  such 
service  stacks.  An  example  for  the  enter¬ 
prise  messaging  system  is  shown  in  Figure 
6  (see  page  14),  which  includes  the  syn¬ 
chronous  messaging  services  and  storage 


Figure  3:  Operational  Node  Connectivity 
Description  (OV-2)  for  the  Enterprise 
Messaging  System 


Figure  4:  Systems  Eunctionality  Description 
(SV-4)  for  the  Enterprise  Messaging  System 


and  security  core  services.  Note  that  a  ser¬ 
vice  consumer  (such  as  IM  and  Chat 
Client)  may  dynamically  connect  to  one  of 
many  chat  servers  that  provide  chat  service. 
In  this  sense,  the  connectivity  is  not  static. 

There  are  situations  such  as  in  securi¬ 
ty  service  or  network  management  ser¬ 
vice  in  which  a  system  communications 
description  (SV-2)  is  more  suitable  than 
SV-1.  This  is  because  such  services  are 
naturally  associated  with  physical  systems 
and  network  elements. 


Figure  5:  Eogical Architecture  Diagram  (SV-1)  for  the  E-mail  Service  in  the  Enterprise  Messaging  System 
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Figure  6:  The  Enterprise  Messaging  System 
Represented  as  a  Service  Stack  (SV-1) 


For  an  SOA,  SV-4  and  SV-1  (or  SV-2), 
capture  the  functional  breakdown  and 
the  logical  or  physical  structures  that  sup¬ 
port  those  functions. 

Traditionally,  system  data  exchange 
matrix  (SV-6)  provides  detailed  data 
exchange  information  between  system 
nodes.  Such  a  matrix  depicts  static  data 
exchange  connections.  In  contrast,  data 
exchange  in  an  SOA  is  specified  by  ser¬ 
vice  contracts  and  a  list  of  consumers  of 
the  services.  Services  can  be  dynamically 
published  through  a  service  broker. 
Consumers  may  then  dynamically  discov¬ 
er,  subscribe,  and  consume  the  services. 
Hence  service  contracts  play  the  role  of 
SV-6  and  the  service  broker  facilitates 
connection  between  consumers  and 
providers. 

For  instance,  the  emerging  Web  ser¬ 
vice  paradigm  uses  Web  Services 
Description  Language  to  describe  service 
contracts.  Simple  Object  Access  Protocol 
is  used  as  the  transport  mechanism.  And 
Universal  Description,  Discovery,  and 
Integration  may  be  implemented  as  part 
of  the  service  broker. 

In  addition  to  SV-6,  other  SVs  may 
also  capture  other  supplementary  proper¬ 
ties  of  a  service.  For  example,  physical 
schemas  (SV-11)  may  be  used  to  describe 
data  schemas  in  a  service  contract,  and 
system  performance  parameters  for  qual¬ 
ity  of  service  or  service  level  agreement. 
The  operational  activity  to  systems  func¬ 
tion  traceability  matrix  (SV-5),  on  the 
other  hand,  shows  how  the  applications 
satisfy  the  requirement  by  supporting  the 
use  cases. 

Technical  View 

The  Technical  View  (TV)  in  an  SOA  is 
the  same  as  traditional  C4ISR  architec¬ 
tures,  with  standards  and  technologies  as 
key  elements.  Here  technical  standards 
profile  (TV-1)  is  essential  because  it  refer¬ 


ences  the  key  technical  standards  and 
technologies  employed  by  the  SOA.  The 
Joint  Technical  Architecture  [7]  provides 
primary  references  for  these  standards 
and  technologies. 

Summary 

Using  UML  techniques  to  supplement 
the  traditional  C4ISR  framework,  I  have 
elucidated  an  approach  for  formulating 
an  SOA.  On  the  operational  side,  it  starts 
with  use  cases,  which  involve  the  interac¬ 
tion  of  two  or  more  operational  or  ser¬ 
vice  nodes.  Mission  functions  are  provid¬ 
ed  through  applications,  which  are  imple¬ 
mented  by  a  set  of  services.  The  corre¬ 
sponding  C4ISR  architecture  products 
are  also  discussed  along  with  an  example. 

In  the  appendices1,  I  also  present  the 
complete  UML  model  for  architectural 
products  in  an  SOA  and  its  mapping  to 
the  Federal  Enterprise  AF.  It  provides  a 
solid  modeling  foundation  for  the  above 
approach. 

When  applied  to  NCES,  this 
approach  was  very  effective.  The  use 
cases  in  the  nine  core  enterprise  services 
of  NCES  drove  the  development  of  the 
architectural  products.  They  also  provid¬ 
ed  a  natural  link  to  the  NCES  require¬ 
ments  and  direct  connection  to  the  end 
users.  After  developing  the  high-level 
architecture  products,  detailed  events  for 
the  use  cases  were  analyzed,  service  inter¬ 
faces  or  contracts  were  defined,  and  met¬ 
rics  for  service  performance  were  estab¬ 
lished. 

Some  topics  for  future  investigation 
on  this  approach  include  how  to  capture 
SOA  products  in  a  Core  Architecture 
Data  Model  database,  which  is  included 
in  the  DoDAF;  how  to  specify  and  man¬ 
age  service  contracts  in  an  SOA  to  ensure 
interoperability  across  the  enterprise;  and 
how  to  evaluate  compatibility  or  compli¬ 
ance  between  different  SOAs.^ 
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Notes 

1.  Additional  details  on  this  and  other 
developments  can  be  found  in  this 
article’s  online  version  at  <www.stsc. 
hill.af.mil/crosstalk>.  In  the  PDF 
version,  click  on  the  appendices  link. 
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Executable  Specifications:  Language  and  Applications 

Dr.  Doron  Drusinsky  and  Dr.  J.  L.  Fobes 

Naval  Postgraduate  School 

With  recent  industry  focus  on  software  safety  and  dependability \  and  with  a  particular  Department  of  Defense  (DoD)  empha¬ 
sis  on  safety-critical  systems,  formal  methods  are  gaining  renewed  attention  as  a  way  to  ensure  that  an  implementation  is  consis¬ 
tent  with  its  specifications.  Unlike  conventional  testing  methods,  which  are  human  intensive  and  therefore  slow,  expensive,  and 
error-prone,  formal  methods  enable  automated  computer-aided  verification.  This  article  describes  an  easy-to-use  formal  method 
based  on  executable  specifications.  In  particular,  it  describes  the  logical foundation  of  executable  formal  specifications,  along  with 
some  interesting  applications  relevant  to  DoD  missions  such  as  run-time  monitoring  of  real-time  systems  and  online  temporal 
rule  checking  for  security -based  applications.  It  also  describes  two  categories  of  techniques  for  executing  formal  specifications. 


Formal  specification  languages  have 
been  thoroughly  investigated  during 
the  past  three  decades.  They  have  been 
considered  primarily  for  verification  and 
validation  purposes  using  techniques  com¬ 
monly  known  as  formal  methods.  Most 
formal  methods  have  suffered  from  limit¬ 
ed  commercial  success  due  to  several  lim¬ 
iting  factors  such  as  their  prohibitive  com¬ 
putational  complexity  and  the  high  level  of 
mathematical  skills  needed  to  be  used 
effectively. 

Recent  research  has  focused  on  exe¬ 
cutable  specifications ,  a  new  class  of  applica¬ 
tions  of  formal  specifications  whereby 
specification  rules  are  executed  on  a  com¬ 
puter  much  like  any  high-level  program¬ 
ming  language.  This  class  of  techniques 
and  associated  tools  harnesses  the  linguis¬ 
tic  power  of  formal  specification  lan¬ 
guages  yet  is  simple  and  does  not  suffer 
from  the  complexity  limitations  of  formal 
verification  methods.  In  addition,  exe¬ 
cutable  specifications  enable  new  applica¬ 
tion  domains  in  addition  to  classical  verifi¬ 
cation  such  as  online  temporal  reasoning 
in  security  applications. 

In  this  article,  we  focus  on  temporal 
logic  that  is  a  particular  and  prominent 
formal  specification  language.  We  begin 
with  background  information  about  logic 
and  formal  methods  and  then  describe 
temporal  logic  in  greater  detail.  Next,  we 
describe  executable  specification  methods 
and  tools  followed  by  a  description  of  a 
successful  verification  effort  using  exe¬ 
cutable  specification.  Lastly,  we  describe 
security  rule-checking  using  executable 
specifications. 

Background 

Formal  specification  languages  are 
designed  to  capture  requirements  (what  a 
system  should  do)  in  a  formal  way,  i.e., 
using  mathematics.  In  contrast,  design  and 
programming  languages  capture  the 
implementation  ( how  a  system  implemen¬ 


tation  does  what  it  is  supposed  to  do). 

Using  mathematical  notation  to  cap¬ 
ture  specifications  removes  potential 
ambiguity  and,  when  coupled  with  mathe¬ 
matical  proof  techniques,  enables  pro¬ 
gram  correctness  proofs.  These  proofs 
provide  indisputable  statements  about  the 
absolute  absence  of  errors  in  the  imple¬ 
mentation.  This  contrasts  with  testing 
techniques  where  only  incomplete  evi¬ 
dence  is  provided.  The  body  of  knowl¬ 
edge  involving  formal  specifications  and 
formal  correctness  techniques  is  com- 

“Using  mathematical 
notation  to  capture 
specifications  removes 
potential  ambiguity 
and,  when  coupled 
with  mathematical 
proof  techniques, 
enables  program 
correctness  proofs.” 

monly  referred  to  as  formal  methods. 

Clearly,  there  is  an  inherent  trade-off 
between  investing  in  the  education  and 
tools  of  formal  methods  versus  the  poten¬ 
tial  benefit  of  assuring  bug- free  software. 
For  example,  a  low-end  Web  site  owner 
might  be  willing  to  take  the  risk  of  having 
program  errors  on  the  site  rather  than 
invest  in  costly  verification  methods.  On 
the  other  hand,  the  cost  of  a  single  bug  in 
the  software  onboard  a  multimillion  dollar 
space  mission  justifies  the  investment  in 
robust  verification  techniques  such  as  for¬ 
mal  methods. 


The  most  popular  mathematical 
domain  used  by  formal  specification  lan¬ 
guages  is  logic.  In  its  simplest  form, 
Boolean  propositional  logic 1  is  the  kind  of 
logic  found  in  every  modern  program¬ 
ming  language  such  as  the  C/Java  expres¬ 
sion  (x>0)  &&  (y==l).  However,  propo¬ 
sitional  logic  is  not  powerful  enough  to 
elegantly  capture  temporal  and  aggrega- 
tional  aspects  of  the  system.  For  example, 
propositional  logic  cannot  explicitly  state 
that  (x>0)  must  be  true  now  and  (y=  =  l)  must 
be  true  sometime  within  the  next  5  seconds. 

First  Order  Logic  (FOL)  extends 
propositional  logic  with  two  quantifiers: 
the  universal  quantifier  (V  read  as  for  all), 
and  the  existential  quantifier  (3  read  as 
there  exists).  These  quantifiers  range  over  a 
known  set,  i.e.,  the  set  of  all  cars  registered 
in  California.  Hence,  a  statement  such  as  a 
California  registered  minivan  must  be  at  most  1 0 
feet  long  can  be  stated  in  a  single  expression: 
Vcar:  minivan  — »  (length<10ft.). 

In  contrast,  using  propositional  logic 
would  require  that  you  explicitly  state  — 
for  every  car  in  the  set  -  the  above  state¬ 
ment.  Also,  using  programming  tech¬ 
niques  to  achieve  the  desired  aggregate 
effect  defeats  the  whole  purpose  of  spec¬ 
ification,  i.e.,  to  make  a  clear  statement 
about  what  the  system  should  do  without 
dealing  with  the  how  it  does  so. 

Linear-Time  Temporal  Logic  (LTL), 
the  formal  specification  language 
described  later  in  this  article  in  the  section 
“REM  Tools:  Code  Generators  and 
Monitors,”  extends  propositional  logic 
with  four  temporal  operators.  LTL  has  an 
advantage  over  FOL  in  that  it  removes 
mathematical  clutter  and  enables  specifi¬ 
cations  in  a  form  that  is  close  to  natural 
language.  It  is  mostly  suitable  for  reactive 
systems ,  i.e.,  systems  that  constantly  interact 
with  their  environment  such  as  control 
software  in  a  cruise  missile. 

Two  primary  classes  of  formal  cor¬ 
rectness  proof  techniques  are  theorem 
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provers  and  model  checkers.  Theorem 
provers  use  logic  proof  methods  to  prove 
that  a  program  conforms  to  a  given  spec¬ 
ification.  Theorem  provers  support  only  a 
subset  of  LTL,  and  typically  require  a 
highly  skilled  human  driver.  Model  check¬ 
ers,  on  the  other  hand,  are  automatic  and 
support  full-blown  LTL  specifications 
(though  typically  with  little  support  for 
real-time  constraint  validation).  However, 
due  to  their  prohibitive  computational 
complexity,  model  checkers  tend  to  work 
well  only  for  small  programs. 

Run-time  Execution  and  Monitoring 
(REM)  is  an  effective  and  efficient  hybrid 
between  formal  methods  and  convention¬ 
al  execution  or  simulation-based  testing 
techniques.  REM  uses  LTL-based  specifi¬ 
cations  augmented  with  real-time  con¬ 
straint  specifications.  REM  is  a  method  of 
automatically  comparing  the  behavior  of 
an  underlying  application  such  as  an 
embedded  system  to  its  formal  specifica¬ 
tion.  This  is  done  by  executing  the  specifi¬ 
cation  in  tandem  with  the  application. 

While  REM  uses  formal  specifications, 
it  is  not  a  pure  mathematical  proof  tech¬ 
nique;  test-based  verification  and  corre¬ 
sponding  test  suites  are  still  required. 
Nevertheless,  REM  is  simple  to  use  and 
automates  the  verification  process.  In 
addition,  REM  tools  described  in  the 
sequel  are  capable  of  detecting  real-time 
requirement  violations  while  executing  on 
an  embedded  target.  Interestingly,  REM  is 
also  useful  for  non-verification  applica¬ 
tions  such  as  security  checking,  as 
described  in  the  “Security  Applications” 
section  of  this  article. 

Formalism  and  Language 
Lessons 

LTL  is  an  extension  of  propositional  logic 
that  deals  with  time  and  order.  As  early  as 
1977,  LTL  was  proposed  as  a  way  to  for¬ 
mally  specify  multithreaded  programs  [1, 
2I\ .  Since  then  —  and  especially  during  the 
last  decade  -  researchers  have  expanded 
its  theoretical  and  practical  power  using  it, 
for  example,  to  specify  protocols  and 
hardware.  LTL  is  a  simple  and  intuitive 
extension  of  propositional  logic  that  is 
closer  to  natural  language  than  most  other 
specification  languages.  For  those  reasons, 
LTL  is  the  formal  specification  language 
used  by  most  formal  methods  and  is  also 
the  specification  language  of  choice  for 
REM  methods  and  tools. 

The  syntax  of  LTL  adds  eight  opera¬ 
tors  to  the  AND,  OR,  IMPLIES,  XOR, 
and  NOT  of  propositional  logic.  Four  of 
the  operators  deal  with  the  future:  Always 
in  the  future,  Eventually  (sometime  in  the 


future).  Until,  and  Next  cycle;  additionally, 
four  dual  operators  address  the  past: 
Always  in  the  past,  Sometime  in  the  past. 
Since,  and  Previous  cycle. 

Metric  Temporal  Logic  (MTL)  en¬ 
hances  LTL’s  capabilities  [3].  With  it,  you 
can  define  upper  and  lower  time  con¬ 
straints  as  well  as  time  ranges  for  the  LTL 
operators.  By  imposing  relative  and  real¬ 
time  constraints  on  LTL  statements,  MTL 
lets  you  use  LTL  to  verify  real-time  sys¬ 
tems.  The  following  is  an  example  showing 
a  relative-time  upper  boundary  in  MTL: 

Always<io(readySignal  Implies  Next 
ackSignal) 

which  reads, 

Always,  within  the  next  10  cycles, 
ready  Signal  equals  1  implies  that 
one  cycle  later  ackSignal  equals  1 . 

The  text  inside  the  parentheses  is  a 
propositional  logic  expression,  and  a  cycle 
is  an  LTL  time  unit,  which  is  a  user-con- 
trolled  quantity.  The  time  constraint  is  rel¬ 
ative  in  that  it  is  counted  in  clock  cycles. 

Another  example  is  as  follows: 

Always  timers, io](readySignal  Implies 
Eventually  timer2>=  20  ackSignal) 

which  reads, 

Always,  between  5  and  10  timerl 
real-time  units  in  the  future, 
ready  Signal  equals  1  implies  that 
eventually,  at  least  20  timer2  real¬ 
time  units  further  in  the  future, 
ackSignal  equals  1 . 

Here,  two  real-time  constraints  are 
specified  using  timerl  and  timer2  clocks. 
A  separate  statement  maps  these  timers  to 
system  calls,  system  clocks,  or  another 
counting  device. 

One  reason  for  the  prominence  of 
LTL  as  a  specification  language  is  the  sim¬ 
ple  way  in  which  it  relates  to  natural  lan¬ 
guage.  For  example,  consider  the  natural 
language  requirement  for  a  traffic  light 
controller  (TLC):  whenever  light  is  red,  light 
should  turn  green  within  two  minutes.  The  fol¬ 
lowing  conversion  steps  convert  the 
requirement  into  an  MTL  requirement. 

1.  Always  when  light  is  red  then  light 
should  turn  green  within  two  minutes. 

2.  Always  (if  light  is  red,  then  light 
should  turn  green  within  two  minutes) 

3.  Always  (light  is  red  implies  that  even¬ 
tually  light  should  turn  green  within 
two  minutes) 


4.  Always  (LightColor==RED  Implies 

Eventually  seconds  <120  LightColor  =  = 

GREEN) 

REM  Tools:  Code  Generators 
and  Monitors 

The  two  primary  categories  of  executable 
specification  tools  are  code  generators  and 
REM  tools  (monitors).  Code  generators 
generate  source  code  in  a  programming 
language  such  as  a  Java,  C  or  C++,  from 
formal,  LTL  specifications.  While  a  con¬ 
ventional  program  can  handle  proposi¬ 
tional  logic,  it  cannot  deal  with  higher 
forms  of  logic  such  as  FOL,  LTL,  or 
MTL.  For  example,  writing  LTL  inside  a  C 
program  will  result  in  compilation  errors. 
Therefore,  an  often-used  solution  embeds 
high-level  specification  requirements 
inside  program  comments. 

For  example,  the  following  C  program 
contains  an  embedded  MTL  assertion  for 
a  TLC  (written  with  syntax  from  [4]) 
asserting  that  for  100  milliseconds,  whenever 
light  is  red,  camera  should  be  on : 

void  tlc(int  Color_Main,  boolean 
CameraOn)  { 

...  /*  Traffic  Light  Controller 
functionality  */ 

/*  TRBegin 

TRCIock{C1=getTimelnMillis()}  // 
get  time  from  the  OS 
TRAssert{  Always({Color_Main  == 
RED}  Implies  Eventually_  Cl 
<1000_{CameraOn  ==  1}) 

}=> 

//  Customizable  user  actions 
{printf(“SUCCESS\n”);printf(“FAIL\n”); 

printf(“DONE!\n”);} 

TREnd  */ 

}  /*  end  of  tic  */ 

An  executable  specifications  code  gen¬ 
erator  generates  code  that  replaces  the 
embedded  LTL/MTL  assertion  with  real 
C  code,  which  executes  in  process  with  the 
rest  of  the  TLC,  i.e.,  as  part  of  the  under¬ 
lying  TLC  application.  The  generated 
code  can  also  be  used  for  formal  specifi¬ 
cation-based  exception  handling  [5] . 

In  contrast  to  code  generators,  REM 
monitors  (e.g.,  [6,  7])  monitor  assertions  in 
a  stand-alone  process  often  on  a  remote 
machine.  It  uses  Hyper  Text  Transfer 
Protocol  (HTTP),  sockets,  or  serial  com¬ 
munication  to  interface  with  the  client 
application.  To  monitor,  these  tools  either 
generate  special,  out-of-process  source 
code  using  a  code  generator  or  use  math¬ 
ematical  tools  such  as  rewriting  systems. 
The  following  list  describes  desired  prop¬ 
erties  of  remote  monitors: 
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1.  Monitoring  online,  namely,  no 
post-mortem  processing  is  used.  A 

counter  example  would  be  to  store  all 
events  in  a  database  and  use  a  struc¬ 
tured  query  language  (SQL) -based 
method  to  query  those  tables  at  a  later 
time.  The  motivation  for  this  require¬ 
ment  is  that  no  expected  termination 
time  for  the  underlying  application 
(e.g.,  security  application)  should  be 
assumed.  With  no  expected  termina¬ 
tion  time,  the  size  of  the  stored  histo¬ 
ry  trace  information  will  be  monoton- 
ically  increasing  and  unbounded, 
which  is  unacceptable  in  most  cases. 

2.  Low  impact.  It  is  desirable  for  a  REM 
tool  to  not  actively  interrogate  the 
client  application  (e.g.,  the  banking  sys¬ 
tem  in  the  R2  example  in  the  “Security 
Applications”  section).  Rather,  it 
should  passively  listen  to  an  event 
stream  pertaining  to  basic  propositions 
such  as  deposit-occurred  or  balance<0 , 
which  is  sent  to  the  REM  tool  from 
the  client  application.  Having  a  low- 
impact  REM  tool  increases  the  likeli¬ 
hood  of  acceptance  by  commercial 
and  security-related  organizations.  For 
example,  a  bank  is  typically  unwilling 
to  be  actively  interrogated  by  a  third- 
party  tool  but  might  agree  to  voluntar¬ 
ily,  on  its  own  terms  and  conditions, 
send  out  limited  information  to  a  third 
party  such  as  a  REM  monitor. 

3.  Powerful  and  flexible  rules  lan¬ 
guage.  Formal  specifications  need  to 
capture  real-life  patterns  and  concerns 
such  as  real-time  constraints  while 
being  syntactically  close  to  natural  lan¬ 
guage.  The  LTL  satisfies  these  require¬ 
ments;  a  large  body  of  research  points 
to  its  expressiveness  and  usefulness  as 
a  specification  language.  The  MTL 
adds  real-time  constraints  to  LTL 
specifications.  Time  series  constraints 
are  also  supported  [8]. 

Run-Time  Monitoring  of 
Safety  Critical  Systems  at  NASA 

NASA’s  Jet  Propulsion  Laboratory  has 
used  REM  to  verify  the  fault  protection 
subsystem  of  the  Deep-Impact  spacecraft 
[9] .  The  level  of  fault  protection  provided 
by  this  system  is  single-fail-operational 
(the  system  has  the  capability  to  recover 
from  a  single  fault  and  continue  its  mis¬ 
sion).  Multiple  faults  are  handled  sequen¬ 
tially  where  only  one  response  is  active  at 
a  time. 

The  fault  protection  provides  moni¬ 
toring  and  system-level  responses  to  faults 
detected  onboard  the  spacecraft.  Other 
missions  that  have  used  this  level  of  fault 


protection  include  Galileo,  Mars  Path¬ 
finder,  and  DSL  Deep-Impact  continues 
with  this  legacy  but  has  incorporated  a 
core  reusable  portion  called  the  Fault 
Protection  (FP)  engine.  The  FP  engine  is 
responsible  for  accepting  all  input  symp¬ 
toms  from  various  monitors  and  generat¬ 
ing  the  appropriate  system  level  response. 
These  responses  may  vary  from  a  single 
command  (reset  a  hardware  device)  to  a 
long  running  sequence  (orient  the  space¬ 
craft  to  a  safe  altitude). 

The  FP  engine  handles  faults  by  prior¬ 
ity-based  input  queues.  The  FP  engine 
ensures  that  responses  are  handled  in  an 
orderly  fashion  and  are  not  run  unneces¬ 
sarily  (triggered  by  an  overly  sensitive 
monitor).  After  each  response  is  run 
through  to  completion,  the  FP  engine 
clears  the  fault  and  sends  a  cleanup  signal 
back  to  the  offending  monitor. 

“Formal  specifications 
need  to  capture  real-life 
patterns  and  concerns 
such  as  real-time 
constraints  while  being 
syntactically  close  to 
natural  language. ” 

REM  was  used  to  validate  the  FP 
engine  software  while  in  the  development 
phase  in  executable  form  although  not 
mature  and  robust;  this  led  to  the  possibil¬ 
ity  of  uncovering  latent  bugs  in  the  soft¬ 
ware.  Many  aspects  of  the  FP  application 
exist  that  lend  themselves  well  to  a  run¬ 
time  verification  approach.  For  example, 
during  runtime  the  developer/tester  may 
be  unaware  of  inconsistencies  within  the 
internal  state  of  the  FP  engine.  Faults  may 
be  locked  into  a  state  where  they  are 
unable  to  trigger  a  response.  Due  to  the 
nature  of  the  application,  there  are  hun¬ 
dreds  of  possible  symptoms  that  may  be 
reported  to  the  FP  engine,  and  dozens  of 
possible  faults  that  can  trigger  responses. 
It  would  be  difficult  for  a  test  engineer  to 
be  constantly  checking  internal  state  con¬ 
sistency.  Using  the  runtime  verification 
approach,  the  REM  monitor  executed  in 
parallel  with  the  application,  alerting  the 
user  to  any  violation  of  pre-defined  cor¬ 
rectness  properties. 

Security  Applications3 

Consider  the  following  two  airline  securi¬ 


ty-related  temporal  pattern  rules,  both 
concerned  with  detecting  a  foreign  nation¬ 
al  male  passenger  with  a  student  visa  fly¬ 
ing  to  the  Harrisburg  International 
Airport  near  the  Three  Mile  Island  nuclear 
power  plant: 

•  Rl.  Detect  such  a  passenger  if  he  has 
traveled  to  the  Middle  East  at  least 
once  within  a  year  of  obtaining  his  stu¬ 
dent  visa. 

•  R2.  Detect  such  a  passenger  if  he  has 
traveled  to  the  Middle  East  at  least 
once  within  a  year  of  obtaining  his  stu¬ 
dent  visa  and  he  received  two  or  more 
direct  deposits  from  non-US  banks 
within  the  last  year. 

Both  rules  describe  temporal  patterns 
that  contain  potentially  discernable  ele¬ 
ments  from  an  airline  security  system 
operating  automatically  and  in  real-time. 
The  two  primary  methods  for  performing 
such  temporal  pattern  detection  are  offline 
and  online ,  as  described  in  the  sequel. 

The  Federal  Aviation  Administration 
has  an  automated  profiling  system  origi¬ 
nally  termed  Computer  Assisted  Passen¬ 
ger  Screening  (CAPS)  [10]  that  relies  upon 
the  data  in  each  Passenger  Name  Record. 
This  profiling  system  is  being  upgraded  to 
access  a  more  extensive  range  of  data. 
The  upgrade,  CAPPSII,  will  profile  airline 
passengers  based  on  secret  criteria  to  iden¬ 
tify  potential  terrorists.  Personal  informa¬ 
tion  about  passengers  may  additionally 
include  that  from  the  Immigration  and 
Naturalization  Service  (INS,  now  U.S. 
Immigration  and  Customs  Enforcement), 
law  enforcement,  and  customs.  Having 
such  history  information  stored  in  the  sys¬ 
tem,  or  in  constituent  subsystems,  enables 
SQL-based  implementation  of  a  temporal 
pattern  rule  such  as  Rl.  We  call  such  an 
implementation  offline  because  it  relies  on 
storing  and  querying  historical  informa¬ 
tion.  An  offline  solution  induces  the  fol¬ 
lowing  three  impact  consequences: 

1.  Temporal  historical  information  is 
stored  within  the  system  (e.g.,  within 
CAPPSII  and/or  its  constituent  sub¬ 
systems). 

2.  Temporal  and  non-temporal  pattern 
detection  is  initiated  by  the  security- 
related  query,  querying  the  constituent 
resources  at  will.  We  regard  this  as  a 
high-impact  solution  because  a  tempo¬ 
ral  query  is  initiated  from  outside  the 
original  scope  of  the  queried  system, 
thereby  impacting  the  performance  of 
the  queried  system.  For  example,  a 
potential  INS  subsystem  of  CAPPSII 
is  impacted  by  repeated  external 
queries  from  CAPPSII  proper  which, 
sooner  or  later,  will  degrade  the  INS 
system  performance.  Performance 
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degradation  will  occur  because  of  the 
actual  query  processing  forced  on  the 
INS  subsystem  and  because  of  the  fact 
that  as  time  progresses,  temporal 
queries  might  query  monotonically 
increasing  data-sets  of  historical  data. 

3.  In  addition  to  performance  issues, 
CAPPSII  and  its  constituent  subsys¬ 
tems  need  to  agree  on  a  shared  data 
representation  for  merging  query 
results  from  multiple  subsystems  (e.g., 
merging  INS  and  law  enforcement 
query  results). 

This  article  is  concerned  with  low- 
impact, ,  online  temporal  pattern  detection.  It 
uses  REM  to  detect  temporal  patterns 
without  using  historical  data  (i.e.,  it  is 
online),  and  without  querying  the  underly¬ 
ing  application  (i.e.,  it  is  low-impact).  The 
only  communicated  information  it 
requires  from  the  underlying  application 
(e.g.,  CAPPSII  constituent  subsystems) 
are  Boolean  messages  for  basic  proposi¬ 
tions  such  as  deposit  of  more  than  $1,000  was 
made  to  account  of  SSN—222  1 1  2222. 

While  pattern  rule  R1  described  earlier 
is  programmable  within  the  suggested 
CAPPSII  framework,  R2  requires  exten¬ 
sion,  which  includes  banking  information. 
Such  an  extension  however  will  not  lend 
itself  to  offline  temporal  pattern  detection 
methods  for  the  following  reasons: 

1.  The  banking  data  systems  only  store 
historical/ temporal  information  for  a 
limited  duration  (e.g.,  three  months). 
The  industry  is  unlikely  to  make  any 
significant  change  to  this  policy. 

2.  Banking  data  systems  are  not  likely  to 
permit  high-impact,  CAPPSII-initiated 
queries  because  of  the  performance 
consequences  discussed  earlier  as  well 
as  their  own  security  need  to  be  in  full 
control  over  any  content  query. 

In  contrast,  a  REM  temporal  pattern 
detection  method,  being  online  and  low- 
impact,  can  be  used  in  tandem  with 
CAPPSII  while  supporting  extensions  that 
support  rules  such  as  R2. 

Conclusion 

Executable  specification  methods  have 
been  effectively  used  to  verify  safety-criti¬ 
cal  systems  at  NASA.  They  enjoy  the 
power  and  accuracy  of  formal  specifica¬ 
tions,  yet  are  easy  to  use.  They  also  enable 
requirement  simulation  prior  to  imple¬ 
mentation.  In  addition,  these  appealing 
properties  of  executable  specification 
methods  lend  themselves  to  non-verifica¬ 
tion  applications  such  as  monitoring  tem¬ 
poral  rules  within  security  applications. ♦ 
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Executable  and  Translatable  Unified  Modeling  Tanguage  (xtUMT),  which  is  a  profile  of  UMT ,  adds  a  standard  execu¬ 
tion  model for  a  tractable  subset  of  the  language  so  developers  can  formally  test  models  to  reduce  defect  rates  from  early  exe¬ 
cution  of  a  target-independent  application  model  before  decisions  have  been  made  about  implementation  technologies.  xtUMT 
separates  application  and  software  architecture  design  so  that  each  can  evolve,  be  maintained,  modified,  and  reused  separate¬ 
ly  and  concurrently.  This  yields  significant  reductions  in  development  cost  and  time  to  market.  In  xtUMT,  design  is  expressed 
as  a  set  of  transformation  rules,  providing  automatic  model  translation.  The  transformation  rules  are  applied  either  uni¬ 
formly  or  to  model  elements  marked  to  indicate  which  rule  to  apply.  This  allows  optimised patterns  to  be  propagated  through¬ 
out  the  code,  providing  powerful  performance  tuning  and  resource  optimisation.  It  also  allows  for  retargeting  models  to  dif¬ 
ferent  implementation  technologies  as  they  change.  This  article  describes  these  fundamental  ideas  behind  xtUMT,  and  how 
they  work  in  practice. 


As  its  key  idea.  Executable  and 
Translatable  Unified  Modeling 
Language  (xtUML)  separates  application 
and  software  architecture  design  and 
weaves  them  together  only  at  deployment 
time  via  the  following: 

•  Application  models  capture  what  the 
application  does  clearly  and  precisely 
The  models  are  executable,  including 
details  relevant  to  the  application  but 
independent  of  the  software  platform 
(i.e.,  design  and  implementation 
details). 

•  Software  architecture  designs  - 
defined  in  terms  of  transformation 
rules  and  execution  engine  compo¬ 
nents  -  are  incorporated  by  a  genera¬ 
tor  that  produces  code  for  the  target 
system.  The  software  architecture 
designs  are  completely  independent  of 
the  applications  they  support. 

•  A  generator,  which  may  be  human, 
weaves  the  application  models  and  the 
execution  engine  components  result¬ 
ing  in  100  percent  complete  code  for 
modeled  components. 

The  complete  separation  of  the  soft¬ 
ware  architecture  design  from  the  applica¬ 
tion  models  supports  concurrent  design 
of  the  application  and  the  software  archi¬ 
tecture,  compressing  the  development 
schedule  and  time  to  market. 

These  benefits  accrue  partly  as  a  result 
of  simplifying  the  tasks  of  analysis  and 
design  because  each  can  be  carried  out  sepa¬ 
rately.  In  particular,  design  is  the  definition 
of  a  set  of  transformations  that  can  be 
applied  to  the  various  analysis  elements. 
Each  design  transformation  rule  thus 
applies  to  all  matching  patterns  in  the  appli¬ 
cation,  significantly  simplifying  the  design 
task.  This  also  enables  automation,  which 
yields  greater  benefits.  For  that  reason,  the 
article  assumes  automation  here. 


xtUML  Notation 

xtUML  defines  a  carefully  selected, 
streamlined  subset  of  UML  to  support  the 
needs  of  execution-  and  translation-based 
development,  which  is  enforced  not  by 
convention  but  by  execution:  Either  a 
model  compiles,  or  it  does  not. 

The  notational  subset  has  an  underly¬ 
ing  execution  model.  All  diagrams  (e.g., 
class  diagrams,  state  diagrams,  activity 

“...just  as  programming 
languages  conferred 
independence  from  the 
hardware  platform, 
xtUML  confers 
independence  from  the 
software  platform, 
which  makes  xtUML 
models  portable  across 
multiple  development 
environments.** 


specifications)  are  projections  or  views  of  this 
underlying  model.  Other  UML  models 
that  do  not  support  execution  such  as  use- 
case  diagrams  may  be  used  freely  to  help 
build  the  xtUML  models. 

The  essential  components  of  xtUML  are 
illustrated  in  Figure  1  (see  page  20),  which 
shows  a  set  of  classes  and  objects  that  use 
state  machines  to  communicate.  Each  state 


machine  has  a  set  of  actions  triggered  by  the 
state  changes  in  the  state  machines  that 
cause  synchronization,  data  access,  and  func¬ 
tional  computations  to  be  executed. 

A  complete  set  of  actions  makes  UML 
a  computationally  complete  specification 
language  with  a  defined  abstract  syntax  for 
creating  objects,  sending  signals  to  them, 
accessing  data  about  instances,  and  exe¬ 
cuting  general  computations.  An  action 
language  concrete  syntax 2  provides  a  nota¬ 
tion  for  expressing  these  computations. 

An  xtUML  model  with  actions  is  not  a 
blueprint  to  be  rewritten  or  filled  out  by 
programmers,  but  an  executable  specifica¬ 
tion.  The  difference  between  an  ordinary 
programming  language  and  a  UML  action 
language  is  analogous  to  the  difference 
between  assembly  code  and  a  program¬ 
ming  language.  They  both  completely 
specify  the  work  to  be  done,  but  they  do 
so  at  different  levels  of  language  abstrac¬ 
tion.  Programming  languages  abstract 
away  details  of  the  hardware  platform  so 
you  can  write  what  needs  to  be  done  with¬ 
out  having  to  worry  about  things  such  as 
the  number  of  registers  on  the  target 
machine,  the  structure  of  the  stack,  or 
how  parameters  are  passed  to  functions. 
The  existence  of  standards  also  makes 
programs  portable  across  multiple 
machines. 

xtUML  allows  developers  to  model  the 
underlying  semantics  of  a  subject  matter 
without  having  to  worry  about  such  things 
as  the  number  of  processors,  the  data- 
structure  organization,  or  the  number  of 
threads.  In  other  words,  just  as  program¬ 
ming  languages  conferred  independence 
from  the  hardware  platform,  xtUML  con¬ 
fers  independence  from  the  software  plat¬ 
form,  which  makes  xtUML  models 
portable  across  multiple  development 
environments. 
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Figure  1 :  The  Structure  of  an  xtUML  Model 


xtUML  Dynamics 

Figure  1  shows  the  static  structure  of 
xtUML,  but  a  language  is  not  meaning¬ 
ful  unless  there  is  a  definition  of  the 
dynamics,  or  how  the  language  executes 
at  run  time.  To  execute  and  translate, 
xtUML  must  have  well-defined  execu¬ 
tion  semantics  —  and  it  does.  xtUML  has 
specific,  unambiguous  rules  regarding 
dynamic  behavior,  stated  in  terms  of  a 
set  of  communicating  state  machines, 
the  only  active  elements  in  an  xtUML 
program. 

Each  object  and  class  (potentially) 
has  a  state  machine  that  captures  the 
behavior  over  time  of  each  object  and 
class.  Every  state  machine  is  in  exactly 
one  state  at  a  time,  and  all  state  machines 
execute  concurrently  with  respect  to  one 
another.  A  state  machine  synchronizes 
its  behavior  with  another  by  sending  a 
signal  that  is  interpreted  by  the  receiver’s 
state  machine  as  an  event.  On  receipt  of 
a  signal,  a  state  machine  fires  a  transition 
and  executes  an  activity,  a  set  of  actions 
that  must  run  to  completion  before  the 
next  event  is  processed. 

State  machines  communicate  only  by 
signals,  and  signal  order  is  preserved 
between  sender  and  receiver  instance 
pairs.  The  rule  simply  enforces  the 
desired  sequence  of  activities.  When  the 
event  causes  a  transition  in  the  receiver, 
the  activity  in  the  destination  state  of  the 
receiver  executes  after  the  action  that  sent 
the  signal.  This  captures  desired  cause  and 
effect  in  the  system’s  behavior.  It  is  a 
wholly  separate  problem  to  guarantee 
that  signals  do  not  get  out  of  order,  links 
fail,  etc.,  just  as  it  is  a  separate  problem 
to  ensure  sequential  execution  of 


instructions  in  a  parallel  machine. 

Each  activity  comprises  a  set  of 
actions  such  as  a  computation,  a  signal 
send,  or  a  data  access.  The  semantics  of 
these  actions  are  defined  so  that  data 
structures  can  be  changed  at  translation 
time  without  affecting  the  definition  of 
computation  —  a  critical  requirement  for 
translatability.  The  actions  in  each  activi¬ 
ty  execute  concurrently  unless  otherwise 
constrained  by  data  or  control  flow,  and 
these  actions  may  access  data  of  other 
objects.  It  is  the  proper  task  of  the  mod¬ 
eler  to  specify  the  correct  sequencing  and 
to  ensure  object  data  consistency. 

The  application  model,  therefore, 
contains  the  details  necessary  to  support 
application  model  execution  verification 
and  validation,  independent  of  design 
and  implementation.  No  design  details 
or  code  needs  to  be  developed  or  added 
for  model  execution:  Formal  test  cases 
can  be  executed  against  the  model  to 
verify  that  application  requirements  have 
been  properly  addressed. 

Those  are  the  rules,  but  what  is  real¬ 
ly  going  on  is  that  xtUML  is  a  concur¬ 
rent  specification  language.  Rules  about 
synchronization  and  object  data  consis¬ 
tency  are  simply  rules  for  that  language, 
just  as  in  C++  we  execute  one  statement 
after  another  and  data  is  accessed  one 
statement  at  a  time.  We  specify  in  such  a 
concurrent  language  so  that  we  may 
translate  it  onto  concurrent,  distributed 
platforms,  as  well  as  fully  synchronous, 
single-tasking  environments. 

At  system  construction  time,  the 
conceptual  objects  are  mapped  to 
threads  and  processors.  The  generator’s 
job  is  to  maintain  the  desired  sequencing 


specified  in  the  application  models,  but 
it  also  may  choose  to  distribute  objects, 
sequentialize  them,  even  duplicate  them 
redundantly,  or  split  them  apart  so  long  as 
the  defined  behavior  is  preserved. 

Model  Compilers 

A  model  compiler  automatically  gener¬ 
ates  target-optimized,  100  percent  com¬ 
plete  code  from  models.  A  model  com¬ 
piler  comprises  two  main  components. 
First,  there  is  an  execution  engine  that 
supplies  the  execution  infrastructure 
such  as  storage  schemes,  action  invoca¬ 
tion,  and  signal  sending.  An  execution 
engine  is  a  specific  set  of  reusable  com¬ 
ponents  that,  when  taken  together,  are 
capable  of  executing  an  arbitrary  exe¬ 
cutable  UML  model.  The  execution 
engine  will  therefore  contain  ways  of 
storing  instances  in  some  form,  possibly 
as  objects,  but  not  necessarily;  some  way 
of  invoking  an  action;  some  way  of 
sending  signals;  some  way  of  reading  an 
attribute;  and  so  forth.  The  selection  of 
the  elements  in  the  execution  engine 
determines  the  system  properties  such 
as  concurrency  and  sequentialization, 
multiprocessing  and  multitasking,  persis¬ 
tence,  data  organization,  and  data  struc¬ 
ture  choices.  These  choices,  together 
with  the  pattern  of  usages  in  the  appli¬ 
cation,  determine  the  performance  of 
the  system. 

Second,  a  set  of  archetypes  specifies 
how  to  translate  an  application  model 
into  code.  Archetypes  are  a  formaliza¬ 
tion  of  the  design  patterns  and  transla¬ 
tion  rules.  The  archetype  describes  when 
it  should  be  used,  the  set  of  patterns  to 
be  applied  in  code  generation,  and  how 
model  components  will  be  populated  or 
utilized  to  build  code.  (Archetype  exam¬ 
ples  are  provided  in  the  next  section.) 
The  combination  of  translated  applica¬ 
tion  code,  legacy  code  that  is  linked,  and 
the  execution  engine  constitutes  the  run¬ 
time  system. 

The  archetypes  use  a  generator  to 
traverse  an  arbitrary  repository  and  pro¬ 
duce  text.  The  repository  contains  the 
meaning  of  application  model,  distinct 
from  the  diagrams.  (The  repository  will 
maintain  graphical  information  too,  but 
that  is  not  of  concern  for  generation.) 
The  logical  structure  of  the  repository 
(the  metamodel)  mirrors  the  semantic 
rules  described  in  the  previous  sections, 
including  the  semantics  of  actions  — 
which  means  that  the  repository  con¬ 
tains  the  entire,  detailed  application 
model. 

The  metamodel  is  a  model  of  xtUML 
using  UML.  It  has  classes  such  as  Class, 
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.Function  PrivateDataMember (  class  class  ) 

.select  many  pdmS  from  instances  of  Attribute  related  to  class ; 
.for  each  pdm  in  pdmS 
${pdm. Type}  ${  pdm. Name}; 

. endf or 


Table  1:  Simple  Archetype 


Archetype 

Generated  Code 

.select  many  states  related  to  instances  of 
class-> [R13 ] StateChart  ->[R14] State  where 
( isFinal==False ) ; 

public : 

public : 

enum  states  e 

enum  states  e 

{NO  STATE=0 , 

{NO  STATE  =  0  , 

.for  each  state  in  states 

Filling, 

.if  (  not  last  states  ) 

Cooking, 

$ {state . Name } , 

NUM  STATES  = 

.  else 

Emptying 

NUM  STATES  =  ${ state. Name} 

. endif ; 

. endf or ; 

}; 

1; 

Table  2:  Example  Archetype 


Attribute,  Event,  State,  Action, 
CreateAction,  and  ReadAction  —  all  the 
concepts  we  have  discussed.  When  we 
draw  a  class  such  as  Batch  in  a  developer 
model  using  an  xtUML-aware  model 
building  tool,  it  creates  an  instance  of 
Class,  with  data  describing  the  class  so 
created  such  as  a  Name  (Batch),  a 
description,  and  the  like.  Similarly,  when 
we  create  an  attribute  amount  of  Batch, 
this  creates  an  instance  of  Attribute  with 
name  (amount),  the  class  it  describes  (a 
reference  to  Batch),  and  a  type  (quantity). 

The  generator  is  a  translation  engine 
that  extracts  application  model  informa¬ 
tion,  interprets  the  archetypes,  and  per¬ 
forms  the  mapping  of  model  compo¬ 
nents  to  generate  complete  code.  (Recall 
that  the  repository  contains  the  actions 
too.)  The  partitioning  of  model  compil¬ 
ers  into  these  pieces  streamlines  their 
customization,  construction,  and  main¬ 
tenance.  Changes  and  additions  can  be 
made  to  the  archetypes  or  run-time 
library  without  having  to  contend  with 
the  details  of  generator  or  repository 
management. 

Generator  Operation 

The  generator  and  the  archetypes  consti¬ 
tute  a  compilation  environment.  When 
generating  code,  the  generator  extracts 
information  from  the  application  model. 
The  generator  then  selects  the  appropri¬ 
ate  archetype  for  the  to-be-translated 
model  element.  The  information  extract¬ 
ed  from  this  model  is  then  used  to  fill  in 
the  blanks  of  the  selected  archetype.  The 
result  is  a  fully  coded  model  component. 

The  archetypes  are  applied  either  uni¬ 
formly  to  certain  kinds  of  model  ele¬ 
ments  (all  classes,  say),  or  to  model  ele¬ 
ments  that  have  been  marked  to  indicate 
which  rule  to  apply.  For  example,  a  class 
could  be  marked  to  indicate  the  proces¬ 
sor  in  which  it  resides,  or  a  state  chart 
could  be  marked  to  show  which  storage 
scheme  (a  list  or  a  table)  to  use,  and  so 
on.  Using  marks  provides  complete  con¬ 
trol  over  the  output  and  enables  perfor¬ 
mance  optimization  at  any  level. 

Population  of  an  archetype  common¬ 
ly  requires  invocation  of  other  arche¬ 
types.  These  newly  invoked  archetypes,  in 
turn,  often  invoke  other  archetypes.  The 
creation  of  code,  for  what  appears  to  be 
one  model  element,  can  ultimately 
involve  several  nested  layers  of  arche¬ 
types  for  multiple  model  elements.  This 
is  fully  automated  by  the  generator.  This 
simple  approach  is  incredibly  powerful 
for  real-life  applications. 

The  simple  archetype  in  Table  1  gen¬ 
erates  code  for  private  data  members  of 


a  class  by  selecting  all  related  attributes 
and  iterating  over  them.  All  lines  begin¬ 
ning  with  a  period  (.)  are  commands  to 
the  generator,  which  traverses  a  reposito¬ 
ry  containing  the  executable  model  and 
performs  text  substitutions. 

${pdm.Type},  as  shown  in  Table  1, 
recovers  the  type  of  the  attribute  and 
substitutes  it  on  the  output  stream. 
Similarly,  the  fragment  ${pdm.Name} 
substitutes  the  name  of  the  attribute. 
The  space  that  separates  them  and  the 
lone  semicolon  (;)  is  just  text,  copied 
without  change,  onto  the  output  stream. 

In  the  more  complete  example  in 
Table  2,  the  archetype  uses  italics  for  ref¬ 
erences  to  instances  in  the  repository, 
underlining  to  refer  to  names  of  classes 


and  attributes  in  the  repository,  and 
noticeably  different  capitalization  to  dis¬ 
tinguish  between  collections  of  instances 
versus  individual  ones. 

You  may  wonder  what  the  produced 
code  is  for.  It  is  an  enumeration  of  states 
with  a  variable  num_states  automatically 
set  to  be  the  count  for  the  number  of  ele¬ 
ments  in  the  enumeration.  (There  is  a 
similar  archetype  that  produces  an  enu¬ 
meration  of  signals.)  The  enumerations 
are  used  to  declare  a  two-dimensional 
array  containing  the  pointers  to  the  activ¬ 
ity  to  be  executed.  You  may  not  like  this 
code,  or  you  may  have  a  better  way  to  do 
it.  Cool.  All  you  have  to  do  is  modify  the 
archetype  and  regenerate.  Every  single 
place  where  this  code  appears  will  then  be 


Figure  2:  Components  of  an  Automated  Solution 
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changed.  Propagating  changes  this  way 
enables  rapid  performance  optimization. 

While  the  generated  code  is  less  than 
half  the  size  of  the  archetype,  the  arche¬ 
type  can  generate  any  number  of  these 
enumerations,  all  in  the  same  way,  all 
equally  right  or  wrong. 

Because  the  archetype  is  a  data  access 
and  text  manipulation  language,  it  can  be 
used  in  conjunction  with  the  generator  to 
generate  code  in  any  language:  C,  C++, 
Java,  or  Ada,  and,  if  you  know  the  syntax, 
Klingon.  We  have  used  xtUML  to  gener¬ 
ate  Very  High  Speed  Integrated  Circuit 
Hardware  Description  Language. 

System  Construction 

Figure  2  shows  how  the  pieces  fit  togeth¬ 
er.  To  build  a  system,  developers  build 
xtUML  models  that  specify  the  desired 
behavior  of  the  application,  and  buy  a 
model  compiler  comprising  a  set  of 
archetypes  and  an  execution  engine.  The 
compilation  process  proceeds  in  two 
phases.  First,  the  archetypes  traverse  the 
model  as  stored  in  the  repository  to  pro¬ 
duce  source  code.  Second,  the  generated 
code  is  compiled  with  the  execution 
engine  library  and  any  handwritten,  lega¬ 
cy,  or  library  code.  The  result  is  the  sys¬ 
tem. 

Examples 

xtUML  has  been  used  on  over  1,400 
real-time  and  technical  projects,  includ¬ 
ing  life-critical  implanted  medical 
devices,  Department  of  Defense  flight- 
critical  systems,  24x7  performance-criti¬ 
cal  fault-tolerant  telecom  systems,  highly 
resource-constrained  consumer  elec¬ 
tronics,  and  large-scale  discrete-event 
simulation  systems. 

One  telecommunications  switch  pro¬ 
ject  with  an  in-house  model  compiler 
generated  in  excess  of  4  million  lines  of 
C++.  One  hundred  percent  of  the  mod¬ 
eled  code  was  generated,  comprising 
over  80  percent  of  the  total  system  code. 
The  system  was  extremely  real-time, 
fault- tolerant,  and  used  over  1,000  dis¬ 
tributed  processors  [1]. 

A  consumer  electronic  project  com¬ 
pared  handwritten  code  with  a  model 
compiler.  The  model  compiler  generated 
faster  code  than  the  handwritten  ver¬ 
sion,  though  it  was  slightly  bigger.  This 
difference  was  traced  to  different  choic¬ 
es  made  for  caching  variables.  Both  the 
handwritten  code  and  the  generated 
code  met  performance  and  size  con¬ 
straints  [2]. 

A  joint  forces  wargaming  system 
built  xtUML  models  of  the  maritime 
portion  of  the  battlespace  and  translated 


them  into  C++  that  runs  on  an  high 
level  architecture-based  distributed  dis¬ 
crete  event- simulation  engine.  The  target 
platforms  were  UNIX  workstations  and 
Windows  boxes.  They  used  a  cus¬ 
tomized  version  of  MC-2020  as  the  base 
for  the  model  compiler.  One  portion  of 
the  simulation  uses  a  special  purpose 
simulation  language  generated  by  arche¬ 
types.  The  model  compiler  was  derived 
from  a  C++  model  compiler  with  simi¬ 
lar  system  characteristics. 

Another  organization  that  has  built 
its  own  model  compiler,  for  sale,  with 
sophisticated  transaction  safety  and  roll¬ 
back  features  reports  between  seven  and 
10  lines  of  generated  C++  for  each  line 
of  action  language.  More  importantly,  all 
that  delicate  code  is  known  to  be  cor¬ 
rect;  it  is  not  handcrafted  by  fallible,  or 
worse,  creative  coders. 

For  a  completely  worked  out,  publicly 
available  example  model,  see  “Execu¬ 
table  UML:  The  Case  Study”  [3]. 

xtUML  Capabilities 

xtUML  provides  a  unique  opportunity 
to  accelerate  development  and  improve 
the  quality,  performance,  and  resource 
utilization  of  real-time,  embedded,  sim¬ 
ulation,  and  technical  systems.  The 
approach  provides  for  the  following: 

•  Fully  customizable  translation  gener¬ 
ating  100  percent  complete,  target- 
optimized  code. 

•  Reduced  defect  rates  from  early  exe¬ 
cution  of  target-independent  appli¬ 
cation  models  by  an  average  of  10 
times  ( not  10  percent). 

•  Accelerated  development  of  prod¬ 
ucts  with  multiple  releases,  growing 
or  changing  requirements,  and  fami¬ 
lies  of  products. 

•  Concurrent  design  and  application 
analysis  modeling  to  compress  pro¬ 
ject  schedules. 

•  Powerful  performance  tuning  and 
resource  optimization. 

•  Effective,  practical  reuse  of  target- 
independent  application  models. 

•  Effective,  practical  reuse  of  applica¬ 
tion-independent  designs. 

•  Reduced  maintenance  costs  and 
extended  product  lifetimes. 

This  article  described  the  fundamental 
ideas  behind  xtUML  and  how  it  works  in 
practice.  These  ideas  are  more  fully 
described  in  [4].^ 
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Note 

1 .  Parts  of  this  article  were  derived  from 
the  draft  for  “MDA  Distilled: 
Principles  of  Model-Driven  Architec¬ 
ture”  by  S.J.  Mellor,  K.  Scott,  A.  Uhl, 
and  D.  Weise,  Addison- Wesley,  2004. 

2.  BridgePoint  provides  an  Object 
Action  Language  that  is  compliant 
with  the  abstract  syntax  standard,  but 
there  is  presently  no  action  language 
(notation)  standard. 
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What  You  Don’t  Know  Can  Hurt  You 


Douglas  A.  Ebert 
McKesson  Corporation 

This  article  provides  senior  managers  with  a  methodology  to  develop  a  metrics  program  that  will form  a  basis  for  management 
decisions.  It  presents  a  series  of  questions  a  senior  manager  should  ask  to  address  business  needs ,  rather  than  just  getting 
informational  briefings. 


There  is  an  old  accounting  adage  that 
states,  “You  can't  manage  what  you 
can't  measure.”  In  the  development 
world  we  certainly  take  this  to  heart. 
Walk  into  any  boardroom  of  any  infor¬ 
mation  systems  development  group  and 
you  will  find  remnants  of  charts,  brief¬ 
ings,  status  reports,  and  analyses  of  all 
types  —  and  yet,  in  the  2003  version  of 
the  Standish  Group’s  “Chaos 
Chronicles”  [1],  only  34  percent  of  all 
information  technology  projects  are 
labeled  successful! 

Maybe  we  just  do  not  have  enough 
metrics.  Some  time  ago  I  had  a  discus¬ 
sion  with  a  project  manager  working  on  a 
large  development  project,  the  manager 
estimated  that  he  and  his  subordinate 
team  leaders  spend  around  30  percent  of 
their  time  preparing  reports  aimed  at 
higher  levels  within  the  company.  These 
reports  culminate  in  monthly  senior 
stakeholder  meetings  attended  by  the 
highest- ranking  members  of  the  busi¬ 
ness,  yet  15  months  into  the  project,  the 
manager  cannot  recall  any  directions  or 
decisions  coming  from  these  meetings. 
This  void  is  in  spite  of  the  fact  that  the 
project  will  come  in  over  a  year  late  and 
that  early  deliverables  have  received  unfa¬ 
vorable  comments  about  their  quality! 

As  senior  managers,  we  have  gone 
astray  somewhere  in  our  metrics  pro¬ 
grams.  It  is  not  enough  just  to  be  fed 
with  data  if  that  data  is  not  able  to  drive 
decisions.  We  could  put  the  old  account¬ 
ing  adage  another  way:  “You  don’t  mea¬ 
sure  because  you  want  to  know,  you  mea¬ 
sure  because  you  want  to  be  in  control!” 

Standard  Metrics  Programs 
Quickly  Become  Stale 

Most  of  us  have  a  standard  set  of  project 
reporting  templates  that  we  expect  our 
development  project  managers  to  fill  out 
periodically.  These  reporting  systems 
evolve  over  time  because  senior  leaders 
really  do  have  a  need  to  know  what  is 
going  on.  The  problem  is  that  without 
any  more  thought  than  this,  managers 
default  to  asking  for  metrics  that  are 


readily  available.  This  includes  things  like 
work  hours  or  resources  spent  to  date, 
defects  uncovered  so  far,  and  the  prox¬ 
imity  to  being  on  budget.  Worse,  without 
any  insight  into  what  we  think  this  data 
shows,  our  project  managers  obediently 
and  simply  provide  that  data. 

While  perhaps  interesting,  this  kind 
of  information  does  not  provide  the 
senior  manager  with  any  basis  of  under¬ 
standing  about  whether  the  project  really 


“As  senior  managers, 
we  have  gone  astray 
somewhere  in  our 
metrics  programs.  It  is 
not  enough  just  to  be 
fed  with  data  if  that 
data  is  not  able  to 
drive  decisions.” 

is  going  well  or  poorly.  Nor  does  it  indi¬ 
cate  if  there  is  anything  he  or  she  can  (or 
even  needs  to  be  able  to)  do  about  it. 
Thus,  project  reviews  become  informa¬ 
tional  briefings,  not  periodic  checkups. 
Watts  S.  Humphrey  says  it  best: 

By  concentrating  on  the  schedule, 
managers  overlook  the  things  they 
can  influence.  These  are  to  start 
jobs  promptly,  provide  adequate 
staffing,  and  ensure  that  the  work 
is  done  in  a  disciplined  and  pro¬ 
fessional  way.  [2] 

What  we  need  is  a  program  that  will 
link  the  requested  metrics  to  business 
objectives  and  provide  “objective  results 
that  can  be  used  in  making  informed 
decisions,  and  taking  appropriate  correc¬ 
tive  actions”  [3].  As  an  important  part  of 
this  program,  our  project  managers  need 


to  know  why  we  think  we  need  this  data. 
Knowing  what  we  think  we  are  getting, 
product  managers  will  be  able  to  suggest 
their  own  methods  and  reporting  tools. 
This  helps  build  a  consistent  approach 
and  provides  a  basis  for  mentoring  as 
well.  Building  a  set  of  metrics  consists  of 
asking  the  following  five  basic  questions. 

I.  What  Do  You  Need  To  Know? 

This  is  not  a  trivial  question  and  is  an 
essential  step  since  it  forms  the  basis  for 
the  entire  metrics  program.  Rather  than 
treating  every  project  alike,  take  the  time 
to  sit  down  with  your  project  manager  to 
define  information  needs  based  not  only 
on  the  specific  nuances  of  the  project,  but 
also  on  the  need  to  be  alerted  if  decisions 
are  required. 

For  example,  it  is  unwise  for  a  senior 
leader  to  fall  into  the  trap  of  making  a 
simple  needs  statement  like,  “I  need  to 
know  if  we  are  on  schedule.”  A  better 
needs  statement  would  be  something  like, 
“I  need  to  know  that  I’ll  stay  on  sched¬ 
ule.”  The  difference  in  these  two  state¬ 
ments  is  not  that  subtle.  The  first  state¬ 
ment  is  a  simple  snapshot  that  may  let  the 
senior  manager  sleep  that  night,  but  does 
not  tell  him  whether  he  should  cancel  his 
upcoming  vacation  time.  More  to  the 
point,  if  the  schedule  is  slipping,  the 
senior  leader  has  no  basis  to  understand 
why  it  is  slipping  and  what  can  be  done 
about  it. 

Then  again,  each  project  is  a  proving 
ground  to  see  if  you  learned  any  lessons 
from  the  last  project.  As  a  senior  manag¬ 
er,  you  always  have  a  need  to  know  that 
with  each  project  you  are  getting  better  at 
something  —  whether  that  something  is 
better  efficiency,  productivity,  or  just  plain 
quality.  With  each  project,  target  metrics 
that  will  help  evaluate  improvement  mea¬ 
sures,  either  to  establish  a  baseline  or 
assess  improvements.  Need  statements 
for  this  category  could  look  like  this:  “I 
need  to  know  that  my  quality  improve¬ 
ments  are  meeting  the  objective,”  or,  “I 
need  to  know  the  volatility  of  require¬ 
ments  during  each  stage  of  develop¬ 
ment.” 
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It  is  interesting  that  when  I  was  a  pro¬ 
ject  manager,  my  senior  managers  would 
regularly  ask  me,  “What  are  you  doing  dif¬ 
ferently?”  But  rarely  would  they  demand 
that  I  demonstrate  my  changes  had  any 
effect!  It  seemed  just  causing  the  disrup¬ 
tion  associated  by  introducing  new 
processes  met  their  expectations. 

2.  What  Questions  Do  You 
Need  to  Ask? 

For  each  of  your  need-to-know  items,  you 
have  to  design  the  questions  correctly  to 
get  useful  information  —  this  is  not  as  sim¬ 
ple  as  it  might  seem.  Again,  many  senior 
managers  ask  for  simple  data  points  such 
as  the  current  project  master  timeline. 
The  project  master  timeline  is  data;  being 
able  to  demonstrate  that  the  project  kept 
to  that  timeline  on  purpose  rather  than  by 
accident  requires  analysis. 

For  example,  let  us  take  the  following 
case:  “I  need  to  know  that  I’ll  stay  on 
schedule.”  One  question  you  might  want 
to  ask  would  be,  “What  is  my  burn  rate  of 
resources  for  each  phase/ task  of  a  project 
compared  to  my  estimates?”  It  should  be 
noted  that  to  answer  this  question,  a  pro¬ 
ject  manager  will  still  need  to  present  the 
traditional  data  points  of  milestones  and 
resources  consumed  in  a  period  of  time. 

Be  watchful  for  events  inside  the  pro¬ 
ject  that  might  create  problems  later.  This 
not  only  includes  scope  creep,  where  new 
requirements  are  being  added,  but  also 
scope  volatility.  A  programming  effort  in 
which  I  was  involved  was  right  on  sched¬ 
ule  for  the  first  eight  months,  although 
during  the  last  month  a  change  in  direc¬ 
tion  caused  changes  in  almost  15  percent 
of  the  requirements.  The  needed  rework 
did  not  really  show  up  as  delays  for  anoth¬ 
er  two  months  and  came  as  a  complete 
surprise  to  senior  managers. 

Here  is  a  hint:  One  good  place  to  look 
for  questions  is  to  challenge  planning 
assumptions.  Assumptions  made  during 
program  planning  are  excellent  informa¬ 
tional  needs  for  the  measurement  process. 
If  the  assumption  is  not  realized,  then 
many  of  the  resulting  schedule  and 
resource  plans  may  need  to  be  re-exam¬ 
ined,  or  replanned.  [4] 

Simplistically,  if  the  project  plan 
assumes  70  percent  availability  of  staff, 
that  becomes  a  key  metric  to  predict  the 
final  project  outcome. 

3.  Why  DoYouThinkThis  Is 
the  Right  Question? 

This  is  the  introspective  part:  Challenge 
yourself  about  each  question  you  believe 
you  would  want  to  ask.  This  requires  you 


to  think  through  to  the  so  what  of  whatev¬ 
er  metrics  you  may  receive  —  to  think 
through  what  you  might  do  with  the  data 
and  what  management  actions  you  might 
take.  This  step  also  prepares  you  to 
defend  your  demand  for  these  metrics. 

For  example,  you  may  explain  your 
rationale  as  this:  “Knowing  the  resource 
burn  rate  compared  to  estimates  will  give 
me  a  glimpse  into  the  solidness  of  the 
project  plan.  If  our  estimates  are  consis¬ 
tently  low,  I  may  have  to  reset  project 
expectations  or  assign  additional 
resources  to  your  team.” 

“One  good  place  to  look 
for  questions  is  to 
challenge  planning 
assumptions.  Assumptions 
made  during  program 
planning  are  excellent 
informational  needs 
for  the  measurement 
process.  ” 

Another  example,  if  your  need-to- 
know  is  that  we  have  been  meeting 
requirements  of  our  quality  program.  A 
need-to-ask  question  could  be:  “What  is 
the  trend  of  SQA  [software  quality  assur¬ 
ance]  violations,  by  type?”  Why  would  you 
want  to  know  this?  Humphrey  says  it  best: 
“When  software  projects  fail,  it  is  usually 
because  a  manager  did  not  insist  that  the 
work  be  done  in  the  right  way”  [2]. 

Here  is  another  example:  “How  do  the 
hours  expended  to  address  customer- 
related  problems  compare  to  my  budget?” 
Why  would  you  want  to  know  this?  Well, 
unless  you  have  the  luxury  of  a  separate, 
dedicated  support  group,  surges  in  cus¬ 
tomer-related  efforts  often  rob  your  pro¬ 
ject  of  essential  resources.  Remember,  if 
you  wanted  to  have  a  good  feeling  that 
you  would  stay  on  target,  this  is  a  question 
you  may  need  to  ask. 

You  may  wish  to  discuss  your  rationale 
with  your  managers.  This  will  give  them 
insight  to  your  needs  and  concerns  and 
allow  them  to  provide  their  own  input. 
Do  not  misunderstand,  though;  this  is  not 
a  voting  situation.  Just  because  there  is  no 
current  process  to  answer  your  questions 
does  not  mean  you  should  not  get  the 
answers. 


4.  What  Measures  Would 
Provide  Input  to  Management 
Actions? 

In  most  cases,  you  may  already  have  some 
idea  of  the  questions  you  need  to  ask. 
Stop  and  refine  those  questions  to  ensure 
you  have  enough  detail  to  take  action.  For 
instance,  knowing  about  SQA  violations 
will  give  you  an  overall  feeling  about  how 
well  your  process  programs  are  being  fol¬ 
lowed.  However,  having  these  violations 
reported  per  project  step  or  phase  may 
highlight  where  your  retraining  efforts 
may  provide  the  biggest  impact. 

This  polishing  question  could  also  be 
asked  like  this:  “Before  I  take  action  to 
correct  a  problem,  what  other  information 
would  I  need?”  If  you  knew  the  distribu¬ 
tion  of  defects  per  module,  reported  by 
severity,  that  would  be  more  useful  in  a 
project  review  than  just  hearing  something 
like,  “We’re  sure  seeing  a  lot  of  prob¬ 
lems!” 

This  is  the  time  to  look  for  collabora¬ 
tive  or  explanatory  evidence.  In  this  last 
example,  it  would  be  interesting  to  com¬ 
pare  SQA  violations  to  defects  per  module 
as  you  would  expect  to  see  a  correlation 
between  the  two.  However,  if  SQA  viola¬ 
tions  are  not  accompanied  by  defects,  it 
could  mean  your  SQA  processes  are  a  lit¬ 
tle  overzealous!  On  one  project,  a  rash  of 
SQA  violations  was  reported  during 
inspections  of  requirements  specifica¬ 
tions.  Upon  further  investigation,  we  dis¬ 
covered  that  the  documents  associated 
with  the  requirements  program  had 
recently  been  automated,  yet  the  SQA 
checklist  still  required  physical  signatures 
by  both  author  and  checker. 

5.  What  Is  My  Objective  for 
Each  Metric? 

Put  another  way,  this  last  question  sets  an 
acceptable  range  of  values  for  each  metric. 
It  is  important  to  set  up  each  of  these  trip 
points  ahead  of  time.  Do  not  wait  to  get  a 
report  before  you  have  to  ask  the  ques¬ 
tion,  “Should  I  be  worried  about  this?” 

For  example,  you  may  wish  to  call  a 
more  in-depth  schedule  review  if  the 
resources  allocated  are  greater  than  10 
percent  of  the  estimated  burn  rate.  Or, 
perhaps  you  have  set  a  goal  of  decreasing 
SQA  violations  in  the  planning  phase  by 
20  percent.  You  must  choose  the  accept¬ 
able  range  of  values  based  on  specific  cir¬ 
cumstances  of  the  project,  including  the 
broader  standards  that  may  be  established 
by  your  company  and  the  maturity  of  your 
project  members. 

This  last  question  also  provides  a  kind 
of  acid  test.  If  there  is  no  unacceptable 
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value  —  if  no  actions  are  forthcoming 
regardless  of  the  report  —  then  this  is  data, 
and  not  a  metric. 

Final  Words  of  Advice 

Here  are  some  final  suggestions  in  build¬ 
ing  a  set  of  metrics: 

•  Avoid  the  simple  answers  —  they  may 
be  good  data  points  but  they  are  gen¬ 
erally  not  helpful. 

•  Metrics  can  have  a  life  of  their  own  so 
avoid  creating  a  monster!  Start  small 
and  grow  with  time.  Remember  that 
collecting  metrics  consumes  project 
resources. 

•  Make  establishing  a  baseline  a  priority 
if  you  do  not  have  one  already. 

•  Listen  after  you  ask  questions.  This 
encourages  participation  and  mutual 
respect. 

•  Remember,  the  primary  purpose  of  a 
metrics  program  is  to  support  change! 
(As  a  corollary;  metrics  programs 
make  very  poor  clubs.) 

•  Push  the  comfort  zone.  You  need  to 
know  what  you  need  to  manage,  not 
what  information  somebody  is  com¬ 
fortable  telling  you.^ 
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Identifying  Essential  Technologies 
for  Network-Centric  Warfare 


David  Schaar 
PRICE  Systems,  EEC 


Network-centric  warfare  (NCW)  is  still  a  concept  that  is  being  defined;  many  find  it  too  intangible  for  comfort.  This  is  an 
attempt  at  materialising  what,  exactly,  will  be  the  important  technologies  for  NC  W. 


Most  people’s  first  encounter  with  the 
term  network-centric  warfare  (NCW) 
ought  to  set  off  their  undefined-buzz- 
word-that-sounds-fancy  radar.  It  appears 
sufficiently  generic  an  expression  to 
encompass  any  computer-based  warfight¬ 
ing  system.  It  is  true  that  there  is  no  dic¬ 
tionary  definition  of  the  term.  This  calls 
for  a  clarification  of  the  sense  it  will  have 
in  this  article:  NCW  is  about  leveraging  exist¬ 
ing  information  assets  using  an  infostructure. 

Now,  let  us  dissect  this  statement: 
The  term  infostructure  is  an  amalgama¬ 
tion  of  the  words  information  and  infra¬ 
structure  -  it  refers  to  the  infrastructure 
used  for  information  sharing.  This  could 
be  anything  from  a  long- wave  military 
radio  network  to  an  office  Local  Area 
Network  (LAN).  The  next  keyphrase  is 
existing  information  assets.  This  establishes 
that  NCW  is  not  about  creating  new 
information,  but  rather  about  using  the 
information  that  is  already  in  our  posses¬ 
sion.  Finally,  the  word  leveraging  is  of  cru¬ 
cial  importance:  We  are  trying  to  make 
better  use  of  what  we  already  have.  Based 
on  these  premises,  NCW  is  about  creat¬ 
ing  battlespace  superiority  through  more 
efficient  use  of  existing  information. 

The  concept  of  NCW  can  be  further 
illustrated  by  an  example.  Think  of  a  sit¬ 
uation  where  Army  tanks.  Navy  ships 
carrying  short-range  missiles,  and  Air 
Force  ground  attack  aircraft  would  be 
deployed  to  take  out  a  mobile  enemy 
command  unit.  Rather  than  each  moving 
independently  toward  the  target,  they 
would  use  a  common  data  network  to 
coordinate  their  efforts.  Each  unit  type 
has  various  sensors  to  track  the  target, 
and  this  data  is  fed  into  the  data  network. 
The  data  is  processed  into  one  single  tar¬ 
get  reading  that  is  returned  to  the  units, 
rendering  much  more  accurate  position¬ 
ing.  As  the  units  move  in  closer  to  the 
target,  they  all  have  the  friendly  tank 
positions  plotted  on  their  map  displays  to 
avoid  friendly  fire  incidents.  The  Navy 
ships  have  real-time  information  on  the 
location  of  the  attack  aircraft  as  the  ships 
get  ready  to  launch  their  missiles.  Finally, 
when  weapons  are  launched,  all  units 


receive  continuous  feeds  on  the  status  of 
the  target  to  optimize  impact. 

Clearly  this  way  of  taking  out  the  tar¬ 
get  is  more  likely  to  have  favorable  results 
at  a  lower  cost  compared  to  a  situation 
where  all  units  act  independently.  It  is 
made  possible  through  intelligent  sharing 
of  information. 


“NCW  [network-centric 
warfare]  primarily 
focuses  on  ...  enabling 
better  awareness  of  the 
enemy  and  friendly 
forces  -  but  also  places 
emphasis  on  improving 
command  and  control 
and  decision  making  as 
well  as  execution  ... 
through  improved 
communications  systems! ’ 


What  will  it  take,  technically,  to 
achieve  this  battlespace  superiority?  This 
article  attempts  to  materialize  what, 
specifically,  the  crucial  components  are 
for  making  it  possible  to  reap  the  benefits 
of  NCW.  The  approach  is  general,  not 
focusing  specifically  on  the  United  States 
or  any  other  military  force. 

The  Functions  in  NCW 

In  their  book  “Network-Centric 
Warfare”  [1],  the  authors  identify  three 
roles  in  the  battlespace  ( battlespace  as 
opposed  to  battlefield  reflects  the  reality 
that  today’s  battles  are  not  necessarily 
fought  in  a  single  geographically  delimit¬ 
ed  theater).  These  roles  carry  out  the 
three  main  functions  —  or  tasks  —  in  the 


battlespace:  1)  achieving  battlespace 
awareness  and  knowledge,  2)  command 
and  control  and  decision  making,  and  3) 
execution. 

These  functions  are  carried  out  by  the 
roles  of  sensors,  decision-makers,  and 
actors,  respectively.  The  concept  of 
NCW  primarily  focuses  on  the  first  of 
the  functions  —  enabling  better  awareness 
of  the  enemy  and  friendly  forces  —  but 
also  places  emphasis  on  improving  com¬ 
mand  and  control  and  decision  making  as 
well  as  execution,  for  instance,  through 
improved  communications  systems. 

An  illustrative  example  of  these  func¬ 
tions  is  a  forward-deployed  reconnais¬ 
sance  squad  determining  the  exact  loca¬ 
tion  of  a  target  [sensor)  and  reporting  this 
back  to  the  command  center.  At  the  com¬ 
mand  center,  the  order  is  given  [decision¬ 
maker)  to  an  aircraft  in  the  area  to  take 
out  the  target  [actor). 

At  the  other  end  of  the  spectrum,  the 
three  roles  can  be  carried  out  by  one  and 
the  same  entity:  An  infantry  soldier  spots 
an  enemy  soldier  (sensor),  determines 
that  he  needs  to  attack  the  enemy  soldier 
(decision-maker),  and  proceeds  to  fire  his 
weapon  against  him  (actor). 

Analysis  Based  on  the  NCW 
Roles 

Splitting  the  analysis  along  these  func¬ 
tions  is  a  good  inroad  to  trying  to  deter¬ 
mine  what  it  will  take  for  NCW  to  be  a 
success.  Of  particular  interest  to  this 
community  is  the  first  function:  How  to 
achieve  battlespace  awareness  and  knowl¬ 
edge.  This  function  is  not  an  effort  to 
gather  more  information;  remember,  we 
are  in  the  business  of  better  using  our 
existing  information  assets.  Rather,  it  is  an 
attempt  to  share  and  process  information 
in  the  best  way  possible.  The  remainder 
of  this  article  will  consist  of  a  closer  look 
at  the  sensor  function. 

Battlespace  Awareness  and 
Knowledge  Analysis 
Methodology 

This  research  is  an  attempt  at  formalizing 
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the  analysis  of  key  technological  areas  for 
enabling  NCW:  How  do  we  find  the 
hottest  information  sharing  nodes  where 
exchange  of  sensor  data  is  the  most  valu¬ 
able?  It  presents  a  methodology  for  cre¬ 
ating  a  relative  ranking  of  the  informa¬ 
tion  sharing  nodes.  The  following  is  a 
description  of  that  methodology. 

The  key  to  the  approach  was  to  start 
with  a  complete  model  of  the  battlespace 
and  from  there,  try  to  %ero  in  on  the  most 
interesting  areas  from  a  NCW  perspec¬ 
tive.  The  chosen  model  would  describe 
all  the  possible  transactions  between 
information  nodes  in  the  battlespace 
such  as  depicted  in  Figure  1.  An  infor¬ 
mation  node  was  equated  with  any  bat¬ 
tlespace  entity  (aircraft  carrier,  fighter 
aircraft,  armored  personnel  carrier). 
Using  a  ranking  methodology,  the  most 
interesting  of  these  nodes  would  be  iden¬ 
tified. 

The  basis  for  the  graph  in  Figure  1 
was  a  matrix  that  described  all  the  possi¬ 
ble  information  transactions.  An  infor¬ 
mation  transaction  involves  an  informa¬ 
tion  supplier  and  an  information  recipi¬ 
ent.  The  information  supplier  translates 
into  a  sensor,  as  described  earlier,  carried 
by  some  battlespace  entity.  The  informa¬ 
tion  recipient  corresponds  to  any  battle- 
space  entity.  For  instance,  there  could  be 
an  aircraft  carrying  photoreconnaissance 
equipment  ( information  supplier) ,  transmit¬ 
ting  image  data  to  a  ground  unit  charged 
with  the  task  of  taking  out  a  target  ( infor¬ 
mation  recipient). 

By  applying  mathematical  methods  as 
described  further  on  in  this  article,  the 
value  of  each  information  transaction 
could  be  assigned  a  relative  value,  which 
in  turn  formed  the  basis  for  a  graph  with 
rankings. 

Initially,  a  list  of  all  main  unit  types  in 
the  battlespace  from  sources  such  as  [2] 
was  created.  For  each  of  these  unit  types, 
a  list  of  all  possible  categories  of  sensors 
that  could  be  carried  was  assembled. 
From  this,  a  matrix  (Figure  2)  was  com¬ 
piled  to  describe  the  value  of  all  possible 
information  transactions  between  the 
entities  in  the  list.  This  approach  was 
inspired  by  John  J.  Garstka’s  method  of 
representing  information  positions  [3]. 
Along  the  x-axis  of  the  matrix  are  listed 
all  possible  suppliers  of  information 
such  as  air  radar  carried  by  an  attack  air¬ 
craft  or  global  positioning  system  (GPS) 
carried  by  an  armored  personnel  carrier. 
Along  the  y-axis  are  all  possible  informa¬ 
tion  recipients  such  as  bomber  aircraft  or 
submarine. 

Each  element  ijk  represents  the  value 
of  information  flow  from  element  k  to 


element  j,  for  example,  the  value  of 
information  flow  from  attack  aircraft  air 
radar  to  a  bomber  aircraft.  In  the  study, 
each  element  was  assigned  an  integer 
value  between  0  (low  importance)  and  2 
(high  importance)  to  determine  the  sig¬ 
nificance  of  the  information  transaction. 

Additionally,  each  column  was  multi¬ 
plied  with  a  weighting  factor  to  indicate 
the  significance  of  the  sensor  being  car¬ 
ried  by  a  particular  unit  type  —  for 
instance  to  account  for  the  fact  that  a 
surface  warfare  ship  will  not  necessarily 
be  carrying  an  air  radar  (low  weighting), 
while  an  anti-submarine  warfare  aircraft 
is  guaranteed  to  be  carrying  a  sonar  (high 
weighting). 

This  resulted  in  a  150  X  25  matrix. 
The  values  in  this  matrix  were  absolute; 
that  is,  they  were  all  measured  along  the 
same  scale  but  they  had  not  been  adjust¬ 
ed  to  reflect  the  relative  importance 
between  them.  Having  the  values  relative 
rather  than  absolute  was  key  to  being  able 
to  graph  their  significance.  The  absolute 
values  were  transformed  into  relative  val¬ 
ues  through  the  following  method: 

•  In  the  interest  of  keeping  the  results 
manageable,  the  matrix  data  was 
grouped  into  aggregate  elements 
according  to  different  rules  for  each 
analysis.  For  instance,  one  analysis 
was  performed  where  aggregate 
groups  of  transactions  based  upon 
the  sensor  type  (e.g.,  air  radar)  were 
created,  and  another  analysis  was 
done  where  groups  based  on  the  car¬ 
rier  unit  type  (e.g.,  ground  unit)  were 
compiled. 

For  illustrative  purposes,  we  will  look 
in  more  detail  at  the  case  where  informa¬ 
tion  suppliers  were  grouped  according  to 
the  sensor  type  as  well  as  carrier  type. 


Figure  1:  Information  Transaction  Graph 


One  supplier  group  was  air  radar  carried 
by  air  units.  In  this  analysis,  one  informa¬ 
tion  recipient  group  was  sea  units.  The 
value  to  be  calculated  was  thus  the  rela¬ 
tive  importance  of  information  flow 
from  air  radar  carried  by  an  aircraft  to  a 
sea  unit.  The  formula  was  the  following: 

Relative  Importance  = 

y 

Matrix^ 

Count 

where, 

j  is  an  element  of  recipient  group, 
k  is  an  element  of  supplier  group, and 
count  is  the  total  number  of  suppliers 
in  the  group. 

The  outcome  of  this  calculation  is  that 
the  relative  value  was  computed  as  the 
sum  of  all  matrix  elements  for  air  radars 
carried  by  aircraft  where  the  information 
recipient  is  a  sea  unit,  divided  by  the  num¬ 
ber  of  air  radars  carried  by  aircraft. 

A  Java  program  was  written  for  these 
calculations  and  for  formatting  the 
results  into  inputs  for  the  Graphviz  tool 
from  AT&T  [4].  Graphviz  was  then  used 
to  produce  illustrative  graphs  such  as  the 
one  in  Figure  3  (see  next  page). 


Figure  2:  Information  Transaction  Matrix 
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Figure  3:  Information  Transaction  Matrix 

Results 

The  graphing  resulted  in  clearly  distin¬ 
guishable  areas  of  interest.  For  informa¬ 
tion  suppliers,  four  sensor  types  were  dis¬ 
tinctly  at  the  top  of  the  list: 

1.  Friendly  unit  positioning  sensors. 

2.  Weather  sensors. 

3.  Enemy  positioning  sensors. 

4.  Imaging  sensors  carried  by  aircraft. 
An  example  of  friendly  unit  position¬ 
ing  sensors  is  a  GPS  system.  Friendly 
units  receive  a  feed  from  the  sensor  on 
the  unit’s  position.  This  creates  a  very 
high  level  of  battlespace  awareness  of 
friendly  units’  whereabouts. 

Weather  sensors  range  from  tempera¬ 
ture  sensors  to  weather  radars  —  anything 
that  may  inform  other  units  of  the  cur¬ 
rent  weather  conditions. 

Enemy  positioning  sensors  are  typi¬ 
cally  radars.  A  fighter  aircraft  may  receive 
a  feed  from  other  friendly  aircraft  track¬ 
ing  the  same  enemy  unit.  Creating  a  fused 
reading  from  the  friendly  aircraft’s  data 
indicating  where  the  enemy  unit  is  ren¬ 
ders  a  more  accurate  positioning  and, 
hence,  better  efficiency. 

Imaging  sensors  carried  by  aircraft  are 
sensors  that  capture  either  still  or  video 
imagery,  either  visible  light  or  infrared. 

On  the  information  recipient  side,  air 
and  sea  units  were  deemed  more  interest¬ 
ing  than  ground  units.  This  reflects  the 
fact  that  these  units  typically  carry  more 
advanced  processing  systems  and  are  able 


to  take  in  information  from  more 
sources.  It  also  illustrates  the  greater 
necessity  for  aircraft  and  ships  to  be  ori¬ 
ented  about  the  whereabouts  of  all 
friendly  units  as  well  as  enemy  units. 

So  what  is  the  impact  of  these  results? 
We  can  draw  the  conclusion  that  the  four 
sensor  types  previously  identified  ought  to 
be  among  the  systems  receiving  particular 
emphasis  in  military  acquisitions.  Similarly, 
they  are  likely  to  be  receiving  particular 
attention  by  equipment  manufacturers. 
Development  of  these  systems  is  likely  to 
be  prioritized. 

One  area  merits  some  extra  thought 
from  a  software  viewpoint:  Looking  par¬ 
ticularly  at  sensor  types  one  and  three, 
data  fusion  -  the  art  of  taking  readings 
on  the  same  phenomenon  from  several 
sources  and  applying  algorithms  to  gen¬ 
erate  a  single,  more  accurate  reading  — 
will  be  of  special  interest.  The  type  of 
data  fusion  in  question  here  is  referred  to 
as  positional  fusion  [5].  Three  component 
tasks  make  up  positional  fusion: 

1.  Data  alignment:  Transforming  sen¬ 
sor  data  into  a  common  frame  of  ref¬ 
erence. 

2.  Parametric  association:  Associating 
observations  into  groups  that  repre¬ 
sent  the  same  entity. 

3.  State  vector  estimation:  Combining 
the  observations  that  result  from  the 
same  entity  into  a  single  estimation  of 
the  entity’s  position  and  velocity. 


Clearly,  this  is  a  very  processing-intensive 
area,  with  a  focus  on  optimized  software. 

While  it  might  be  considered  stating 
the  obvious,  it  should  also  be  pointed 
out  that  software  areas  of  general  rele¬ 
vance  to  NCW  are,  among  others,  net¬ 
work  operating  systems,  network  inter¬ 
face  software,  and  communications 
applications. 

The  Next  Step 

In  a  look  further  down  the  line,  one 
author  [6]  envisions  a  departure  from 
direct  connections  between  a  sensor  and 
the  user.  Rather  than  each  unit  carrying 
its  own  sensors,  there  would  be  so-called 
data  fusion  nodes  to  which  both  suppliers 
and  consumers  of  information  would 
connect.  This  would  be  a  hub  of  sorts, 
with  a  task  manager  that,  when  a  request 
for  information  arrives,  directs  the  job  to 
the  sensor(s)  with  the  best  quality,  capa¬ 
bility,  and  availability.  Data  fusion  would 
then  be  moved  away  from  users  into  this 
centralized  location. ♦ 
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Letter  to  the  Editor 


Dear  CROSSTALK  Editor, 

Paul  McMahon’s  article,  “Bridging 
Agile  and  Traditional  Development 
Methods:  A  Project  Management 
Perspective”  in  the  May  2004  edition 
of  Crosstalk  on  bridging 
between  agile  and  traditional  devel¬ 
opment  methods  may  have  missed 
the  real  point.  An  on-site  customer 
representative  for  a  subcontractor  in 
an  environment  where  the  customer 
is  encouraged  to  change  require¬ 
ments  can  have  serious  risks,  not  only 
for  the  prime,  but  also  for  all  of  the 
other  subs  that  have  to  adjust  to 
those  changes.  Integration  is  far 
harder  than  straight  development 
precisely  because  the  communication 
cost  of  keeping  the  various  pieces 
working  together  is  large. 

Often  embracing  change  means 
never  having  to  get  it  right.  This  has 
been  a  primary  cause  of  failure  on 
many  so-called  agile  projects.  (The 
most  famous  XP  project  was  what 
should  have  been  a  routine  payroll 
system  at  Chrysler  that  was  cancelled 
prior  to  completion  due  to  cost  over¬ 
runs  and  late  deliveries  of  needed 
functionality.) 

Good  up-front  architecture  and 
good  design  mitigate  the  risks.  Both 
the  architecture  and  the  implemented 
design  need  to  allow  for  managed 
change.  McMahon  does  this  by  adding 
process  weight  to  agile  methods  in  the 
form  of  his  recommendations. 

Actually,  I  believe  that  his  modifi¬ 
cation  to  the  waterfall  model,  or 
some  other  similar  modifications,  are 


pretty  common  to  successful  devel¬ 
opment  regardless  of  whether  any 
subcontractors  are  agile  or  not. 

So,  I  would  contend  that  the  real 
point  of  McMahon’s  article  is  that  suc¬ 
cessful  development  is  not  about  adapt¬ 
ing  to  XP  by  moving  toward  the  middle. 
It  is  about  the  middle  being  in  the  right 
place  in  the  first  place  because  extremes 
in  either  direction  create  extreme  risks. 
The  XPers  need  to  move  toward  the 
middle  as  well.  If  they  ever  want  to  build 
in  a  true  system- of- systems  environ¬ 
ment,  they  will  recognize  that  while 
change  is  itself  a  requirement,  it  needs  to 
be  accepted,  managed,  and  controlled, 
but  not  embraced. 

For  a  humorous,  yet  capable, 
description  of  the  pitfalls  (and  posi¬ 
tives  as  well)  of  XP,  check  out  the 
book  “XP  Refactored,”  by  Matt 
Stephens  and  Doug  Rosenberg.  It  is  a 
combination  of  clinical  dissection  and 
gossipy  tell- all  about  XP.  And  the  only 
thing  extreme  about  it  is  the  humor. 

Gary  A.  Ham 
Senior  Research  Scientist 
Battelle  Memorial  Institute 
(540)  288-5611  (office) 
(703)  869-6241  (cell) 

The  opinions  in  this  letter  are  the 
author’s  and  do  not  represent  Battelle 
Memorial  Institute  as  a  whole. 
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and  Shoe  Polish 


BackTalk 


I  am  writing  this  column  on  a  flight 
from  Albuquerque  to  Salt  Lake  City 
on  route  to  the  2004  Systems  and 
Software  Technology  Conference. 
Before  we  took  off,  the  pilot  triggered 
the  microphone  and  made  basically  the 
following  announcement:  “Good 
morning  ...  uh  ...  this  is  your  cap¬ 
tain.  We’re  on  flight  ...  uh,  1577  ... 
from,  uh,  ...”  The  speech  seemed 
to  go  on  forever,  punctuated  at  fre¬ 
quent  intervals  by  long  pauses  and 
“uhs.”  The  person  sitting  in  the  seat 
next  to  me  remarked,  “I  sure  hope 
that  he  can  fly  the  plane  better  than 
he  can  talk!” 

I  guess  I  am  getting  old  and 
crotchety  (no  e-mail  acknowledge¬ 
ments,  please!).  But  I  have  noticed 
that  when  cockpit  personnel  key 
the  mike  to  give  us  updates,  some¬ 
times  it  appears  that  they  don’t  under¬ 
stand  that  speaking  skills  convey  an 
impression.  Having  a  competent  airline 
pilot  unable  to  form  a  complete  sen¬ 
tence  in  less  than  90  seconds  of  mike 
time  —  well,  it  makes  me  worry.  (Before 
I  get  banned  from  future  airline  flights, 
I  do  understand  that  the  pilot  was 
probably  completing  a  checklist  and 
making  the  announcement  at  the  same 
time.  And  the  checklist  was  much  more 
important.  Still,  the  rambling  an¬ 
nouncement  did  little  to  inspire  pas¬ 
senger  confidence). 

You’ve  all  heard  the  expression, 
“Put  your  best  foot  forward.”  Well, 
sometimes  it  helps  to  put  a  bit  of  shoe 
polish  on  the  foot,  too.  Oftentimes,  we 
forget  that  appearances  really  count. 
Many,  many  years  ago,  I  had  the 
opportunity  to  make  a  proposal  for 
some  consulting  work.  While  I  did  the 
background  material,  one  of  my  co¬ 
workers  was  responsible  for  the  sales 
pitch  itself.  I  had  crunched  the  num¬ 
bers  and  submitted  accurate  and  up-to- 
date  information  for  the  sales  pitch. 
Imagine  my  amazement  to  find  out 
that  the  sales  pitch  was  accomplished 
on  hand-scribbled  overheads.  The 
company  we  were  presenting  our  sales 
pitch  to  was  also  probably  amazed  to 
find  the  name  of  their  company  incor¬ 
rectly  capitalized!  Needless  to  say,  we 


were  not  overwhelmed  by  their  desire 
to  give  us  business! 

I  think  that  as  engineers  we  some¬ 
times  forget  that  format  is  at  least  as 
important  as  content.  As  a  software 
engineer,  I  often  need  to  present  infor¬ 
mation  and  documents  to  customers 


and  users.  I  recently  watched  another 
engineer  give  a  presentation  using  an 
out-of-focus  projector  that  was  partial¬ 
ly  blocked  by  his  own  laptop.  After  his 
15-minute  presentation  was  over,  the 
next  speaker  moved  and  focused  the 
projector  —  and  many  in  the  audience 
applauded.  Nobody  had  really  been  lis¬ 
tening  to  the  presentation;  they  were 
concentrating  on  the  annoyingly  out- 
of-focus  projector. 

Documentation  falls  under  the 
same  umbrella.  Tables  of  content,  lists 
of  figures,  easy-to-use  indexes  —  these 
all  give  you  a  good  feeling  about  the 
content  of  the  material.  If  it  looks 
good  then  there  is  the  perception  that 
it  also  contains  good  information. 
While  I  am  not  suggesting  for  a 
moment  that  a  glitzy  color  cover  and 
fancy  formatting  will  cover  up  poor 
quality  material,  I  am  suggesting  that 
misspellings  and  sloppy  formatting  will 
cover  up  good  quality  material. 
Recently,  I  presented  a  report  to  a  cus¬ 
tomer,  and  accompanying  the  report 
was  a  backup  CD  with  data.  I  had 
labeled  the  CD  with  a  felt-tip  marker. 
My  co-worker  saw  what  I  was  doing, 
and  without  saying  a  word,  went  and 
printed  a  CD  label  with  some  simple 
artwork.  It  made  a  world  of  difference! 
The  message  was  that  I  had  taken  care 
of  the  details  —  and  it  made  the  cus¬ 


tomer  have  more  confidence  in  every¬ 
thing  else! 

And,  last  but  not  least  —  recognize 
that  not  every  person  has  been  given 
the  ability  to  speak  in  front  of  an  audi¬ 
ence.  I  have  worked  on  team  presenta¬ 
tions  where  the  senior  team  member 
gave  the  briefing.  Unfortunately, 
being  the  senior  member  didn’t 
translate  into  speaking  ability.  A 
mumbling,  stumbling  monotonic 
report  did  little  to  impress  the  lis¬ 
teners;  the  important  message  our 
team  was  trying  to  convey  was 
quickly  lost  due  to  lack  of  interest. 

Impressions  are  quick  to  form, 
and  hard  to  forget.  Do  not  let 
good  research  and  good  work  go 
ignored  because  of  a  lack  of  fol¬ 
low-through.  No  matter  how  you 
present  your  work  to  others,  you 
want  the  presentation  to  convey  this 
message,  “This  is  high-quality  work!” 

So,  when  you  go  to  put  your  best 
foot  forward,  consider  that  a  good  coat 
of  shoe  polish  will  help  make  a  good 
impression. 

—  David  A.  Cook 

Senior  Research  Scientist 
The  AEgis  Technologies  Group,  Inc. 

dcook@aegistg.com 
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